Re: Convince me to switch to Digikam (Was: Exaile - a Gtk+-based Amarok Clone)
On 16/01/07, Amos Shapira [EMAIL PROTECTED] wrote: On 15/01/07, Dotan Cohen [EMAIL PROTECTED] wrote: Thanks. Why doesn't Google know about that page? The latest they seem robots.txt, or that google-invented web site map? Apparently they're using the former and not the later! to have available for download is 0.8.2-3. 0.9.x are in experimental and I don't see how to get at them. If you could repackage your 0.9 I'd love to give it a spin. A link is on the way in private mail. My reply regarding such is in private email as well. Thanks. Dotan Cohen http://lyricslist.com/lyrics/lyrics/48/402/pink_floyd/pulse.html http://what-is-what.com/what_is/voip.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux on Windows
On 16/01/07, Amit Aronovitch [EMAIL PROTECTED] wrote: btw, seems that there's an alpha version of QEMU for windows (don't know about it's usability status). Works great. I've got it running DSL in a windows on any winbox I sit down to. It's not too slow, and network connections, printers, USB are are recognised. I downloaded it from some site that pushes it as a safe way to browse the web in Windows: it leaves no traces of the activity on the winbox. It is also set up to browse via a proxy though I don't use that feature. Google those features, as I can't find the site right now. Dotan Cohen http://what-is-what.com/what_is/ubuntu.html http://gmail-com.com/howto/filters.php = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux on Windows
On Tue, Jan 16, 2007 at 10:50:10AM +0200, Dotan Cohen wrote: On 16/01/07, Amit Aronovitch [EMAIL PROTECTED] wrote: btw, seems that there's an alpha version of QEMU for windows (don't know about it's usability status). Works great. I've got it running DSL in a windows on any winbox I sit down to. It's not too slow, and network connections, printers, USB are are recognised. I was using it to run Linux on an emulated handheld device that I was working on. It ran at about 20% of the CPU speed, which was not too bad. For example, a 1gHz PIII ran it equivalent to a 200mHz PI. A 3.2 gHz PIV or equivalent would run fast enough to watch most low res videos. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 Fax ONLY: 972-2-648-1443 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux on Windows
On 16/01/07, Geoffrey S. Mendelson [EMAIL PROTECTED] wrote: On Tue, Jan 16, 2007 at 10:50:10AM +0200, Dotan Cohen wrote: On 16/01/07, Amit Aronovitch [EMAIL PROTECTED] wrote: btw, seems that there's an alpha version of QEMU for windows (don't know about it's usability status). Works great. I've got it running DSL in a windows on any winbox I sit down to. It's not too slow, and network connections, printers, USB are are recognised. I was using it to run Linux on an emulated handheld device that I was working on. It ran at about 20% of the CPU speed, which was not too bad. For example, a 1gHz PIII ran it equivalent to a 200mHz PI. A 3.2 gHz PIV or equivalent would run fast enough to watch most low res videos. I should be noted that while Windows=2000 will not run on anything less powerful than 533 mHz PIII, Linux runs fine on older/ outdated hardware. So 200 mHz is enough. You can also understand how much better Linux runs on borderline hardware than Windows. That's something to consider when one thinks that he needs to purchase a new computer to run a 'better' operating system. Dotan Cohen http://technology-sleuth.com/long_answer/what_are_the_advantages_of_lcd_monitors.html http://lyricslist.com/lyrics/artist_albums/285/journey.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
And can something be done about it ?? Just as an example at how ludicrous the situation is (and the reason that my relatively powerful laptop is grinding to a halt at the most opportune times of the day), disregarding the things that need to be big, such as Evolution which I'm willing to let go at the moment although it does take up 1 - 1.5GB of virtual memory, here is the list of the things that I don't understand: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. 3166 odeda 18 0 186M 23408 10932 S 0.0 0.6 1:20.29 gnome-panel --sm-config-prefix /gnome-panel-IoBUz The panel is kept busy on my system with quite a lot of applets - but it still is no excuse for 186MB of memory, mainly as applets are out-of-process and counted separately.. lets look at what applets are doing: 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, almost 20% of my total dynamic memory. I cringe to think about what people with 512MB memory do. 3490 odeda 15 0 131M 7308 5456 S 0.0 0.2 0:26.75 mono /usr/lib/tomboy/Tomboy.exe --panel-applet -- Note taking application. written in mono, so I'll let it go. 3327 odeda 15 0 120M 5336 4504 S 0.0 0.1 0:01.03 /usr/libexec/trashapplet --oaf-activate-iid=OAFII The trash applet ? its a frigging two-state icon, with a tooltip that counts the number of items in the trash folder - why does it need 120MB of memory ?? 3307 odeda 15 0 115M 6188 4612 S 0.0 0.2 0:55.20 /usr/libexec/gnome-netstatus-applet --oaf-activat Here's another network applet - this one shows wireless signal. Unlike its brother, this one doesn't have a history - I guess that's why it only takes 115MB of memory !! I took a snapshot of this right after my system wasn't responding and I had to ssh from another computer and kill some processes before I managed to get in, so this doesn't list some other stuff which eats a lot of memory, such as the sensor applet (~180MB), the task bar applet (~150MB !!) and gaim - which is a nice IM and all, but shouldn't take close to 300MB of memory. Just for comparison, I also use some KDE apps (that are written in bloated C++, right ?): Amarok (fully loaded with about 3GB of music to monitor): ~200MB Kopete (under same conditions as GAIM): ~70MB Kmail (under same conditions as evo above): ~110MB Basket (a note taking application - here as a comparison with GNOME applets - its not an applet, but it is constantly running and has a rather complex UI and carries more data for me then tomboy above): ~40MB Now before you go all its only virtual, who cares, I'll have you know that my OS is set up with 2GB of swap for 1GB of dynamic memory, which I always thought was good enough for almost everything, and still - when I have firefox, evolution, some text editors and maybe some file manager windows (in additions to the stuff I always keep running, of course) switching is a pain. If I want to add a serious IDE to the mix, I know I'm risking it. And every so often - about twice a week - I get a system that is so unresponsive due to swap thrashing (if I log in remotely I can see swap at 100% and kswapd taking up all the resources), that I have to kill X just to gain control over it. Except for switching back to KDE - any idea what I can about this ? -- Oded ::.. Chaos is but unperceived order. -- Fred Hoyle = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: kiba-dock howto for FC6 (an Eye Candy from the Beryl family)
On 16/01/07, Ira Abramov [EMAIL PROTECTED] wrote: Quoting Amos Shapira, from the post of Sun, 14 Jan: On 14/01/07, Beni Cherniavsky [EMAIL PROTECTED] wrote: Doing cvs update in the middle of somebody's big commit, you risk getting an inconsistent state. With a project having such frequent commits, this risk is non-negligible. stop the commit to fix a merge problem you are still stuck with the new version of the files he already finished with in this commit cycle. With all this is true to huge project I agree, but this is a few dozen KB, and the commits are practically atomic. Not necessarily - someone starts a commit cycle and finds out that he forgot to add or tweak one of the very few files and there you are. Also possibly the long-distance commit might introduce longer commit cycles or even cause commits to fail half-way through. It starts to feel like a theoretical discussion so let's get over with it - I was already accused of being antisemitic on other forums so we can stop here...:) Cheers, --Amos
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card's RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment. http://gentoo-wiki.com/FAQ_Linux_Memory_Management#The_difference_among_VIRT.2C_RES.2C_and_SHR_in_top_output = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
--=-Yb50PNKHYNSNAArM+xQe Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card's RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment. I'm assuming that shared library mmaped are counted in the shared section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ? I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer. -- Oded ::.. Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is. -- Barbara Bush (Former US First Lady) --=-Yb50PNKHYNSNAArM+xQe Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.12.2 /HEAD BODY On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: BLOCKQUOTE TYPE=CITE PRE FONT COLOR=#00VIRT stands for the virtual size of a process, which is the sum of/FONT FONT COLOR=#00memory it is actually using, memory it has mapped into itself (for/FONT FONT COLOR=#00instance the video card's RAM for the X server), files on disk that/FONT FONT COLOR=#00have been mapped into it (most notably shared libraries), and memory/FONT FONT COLOR=#00shared with other processes. VIRT represents how much memory the/FONT FONT COLOR=#00program is able to access at the present moment./FONT /PRE /BLOCKQUOTE BR I'm assuming that shared library mmaped are counted in the quot;sharedquot; section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ?BR BR I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD --BR OdedBR ::..BR quot;Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is.quot;BR nbsp;nbsp;nbsp;nbsp;-- Barbara Bush (Former US First Lady)BR BR /TD /TR /TABLE /BODY /HTML --=-Yb50PNKHYNSNAArM+xQe-- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Oded Arbel wrote about Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: And can something be done about it ?? I'll offer only partial explanations; I hope that someone else can offer better exlanations, and/or a solution. Of course, my own solution is simple: I don't use neither Gnome, nor KDE. I hand-pick individual applications which I like. I picked a window manager (called ctwm), an editor, clock, and so on, each separately based on their own merits. And one of these merits were memory use (my home computer has just 256 MB of memory, so low memory use is very important for me). PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. Maybe you already know this, but let me just verify that we're on the same page. VIRT is the amount of virtual memory that the process has mapped. It isn't certain that all this memory is used, or ever been used - it is possible that the program allocated some memory and never used it and it doesn't take up space anywhere (I'll get back to this issue shortly). Even stranger (but true), it is possible that this virtual memory isn't RAM at all, but a mapping of a file (such as a shared library), or of something else. In the X server case, it is very common for the server to map the graphic card's memory, which often results in very high virtual memory figures for the X server. The RES figure is the amount of memory that the program now currently uses. You can see that the X server actually uses much less memory than that VIRT figure. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. What can explain huge VIRT size and small RES figure at the same time? I can offer several possibilities - I don't know which of these applies to Nautilus (or your other examples): 1. Software which only knows how to grow, but not shrink. Consider for example Firefox; At some stage in time, you had 10 tabs open, each with very complex pages. Later, you close all the tabs but one, but none of the free()ed memory is actually returned to the system. All this unused memory wasted space in the swap, but doesn't waste RAM. This sort of problem is very common for monolithic programs (which, unlike the original Unix philosophy, don't run quickly and exit, and don't run subprocesses). 2. Programs which uses a lot of threads. Each thread has its own stack; In Linux, these stacks have fixed sized (they don't grow dynamically like the heap) and needs to be allocated in advance. Traditionally, each thread had a 8 MB stack, so if your program had 10 threads, it would allocated 80 MB of virtual memory even without doing a thing! This 80 MB would turn up on the VIRT number but would not actually consume any resources (not RAM and not swap space). If I remember correctly, the per-thread stack size was later reduced to 2 MB which is more reasonable, but still can explain some of the VIRT size for multi-threaded programs. 3. Programs which use a lot of shared libraries. Shared libraries are great. They allow executables to be smaller, and less memory to be used when a lot of applications are running. However, when a program uses a shared library, it maps it into memory, and the shared library size gets added to the VIRT number. Gnome and KDE applications use tons of shared libraries, so even before they allocate a single byte, a huge size is already added to their VIRT figure. Note that while shared libraries increase the VIRT figure, they do not actually consume resources (RAM or swap space), so they are not bad. Check out /proc/.../maps to see which shared libraries are mapped by some process. 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, What worries me here is not the 181M VIRT figure (which like I explained, could mean nothing), but rather the 32 MB RES figure. This crappy applet really takes up 32 MB of your real RAM. This is inexcusable. Just to compare, here are some RES figures for a few
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. This field is sometimes confusing, here is why: Logically, you would expect this field really shows whether your program is partially swapped out and how much. But the reality shows otherwise. Even the Swap used field shows 0, you will be surprised that SWAP field of each tasks show greater than zero number. So, what's wrong? This comes from the fact that top use this formula: VIRT = SWAP + RES or equal SWAP = VIRT - RES As explained previously, VIRT includes anything inside task's address space, no matter it is in RAM, swapped out or still not loaded from disk. While RES represents total RAM consumed by this task. So, SWAP here means it represents the total amount of data being swapped out OR still not loaded from disk. !!! Don't be fooled by the name, it doesn't just represent the swapped out data. !!! http://www.linuxforums.org/misc/using_top_more_efficiently_3.html On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: VIRT stands for the virtual size of a process, which is the sum ofmemory it is actually using, memory it has mapped into itself (forinstance the video card's RAM for the X server), files on disk thathave been mapped into it (most notably shared libraries), and memoryshared with other processes. VIRT represents how much memory theprogram is able to access at the present moment. I'm assuming that shared library mmaped are counted in the shared section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ? I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer. -- Oded ::.. Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is. -- Barbara Bush (Former US First Lady) -- Constantine Shulyupin Embedded Linux Consultant 054-4234440 http://linuxdriver.co.il/
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Hello Oded, people... Few weeks ago, I worked temporarily at a small company, and they gave me a PC which was with Athlon XP (if I recall it was 1.6 Ghz or something) with 756MB RAM to work with. So, I installed CentOS 4.4, upgraded my KDE 3.5.5, and upgraded OpenOffice to the latest one, and used FireFox 2 for browsing. I started to work. I started to use OpenOffice to write a small spreadshot. BOY was it slow as hell! it was so slow that I was almost sure I had some Pentium 2 300Mhz processor. Switching apps (using ALT TAB) was a PITA. I have not been running many applications: Twinkle, Kopete, FireFox, KMail, OO, and Konsole. Nothing more. The machine was crawling. I took Office 2003 from the Windows team, installed Crossover 6 (the latest version finally solves the flickering flash bug), and started to use Office 2003. Finally I could write somthing without the machine being crawling, but opening few more tabs in FF 2, and the machine crawled again.. My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. Today, everyone is laughing/amazed by the hardware requirement of Windows VISTA (specially with Aero Glass interface). Well, my friends, at this pace, GNOME (and maybe even KDE) is going at this way, with all the latest GLX eye-candy, and the hefty memory requirements. I do not know the future, but I do remember KDE usage only few years ago with a Pentium 4 1.7Ghz, 512MB RAM, and it was very usable and enjoyable. Thanks, Hetz On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? Just as an example at how ludicrous the situation is (and the reason that my relatively powerful laptop is grinding to a halt at the most opportune times of the day), disregarding the things that need to be big, such as Evolution which I'm willing to let go at the moment although it does take up 1 - 1.5GB of virtual memory, here is the list of the things that I don't understand: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. 3166 odeda 18 0 186M 23408 10932 S 0.0 0.6 1:20.29 gnome-panel --sm-config-prefix /gnome-panel-IoBUz The panel is kept busy on my system with quite a lot of applets - but it still is no excuse for 186MB of memory, mainly as applets are out-of-process and counted separately.. lets look at what applets are doing: 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, almost 20% of my total dynamic memory. I cringe to think about what people with 512MB memory do. 3490 odeda 15 0 131M 7308 5456 S 0.0 0.2 0:26.75 mono /usr/lib/tomboy/Tomboy.exe --panel-applet -- Note taking application. written in mono, so I'll let it go. 3327 odeda 15 0 120M 5336 4504 S 0.0 0.1 0:01.03 /usr/libexec/trashapplet --oaf-activate-iid=OAFII The trash applet ? its a frigging two-state icon, with a tooltip that counts the number of items in the trash folder - why does it need 120MB of memory ?? 3307 odeda 15 0 115M 6188 4612 S 0.0 0.2 0:55.20 /usr/libexec/gnome-netstatus-applet --oaf-activat Here's another network applet - this one shows wireless signal. Unlike its brother, this one doesn't have a history - I guess that's
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:27 +0200, Nadav Har'El wrote: Of course, my own solution is simple: I don't use neither Gnome, nor KDE. I hand-pick individual applications which I like. Not an option for me, but thanks for the offer :). I like to have my apps tightly integrated. X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. The RES figure is the amount of memory that the program now currently uses. You can see that the X server actually uses much less memory than that VIRT figure. As I've said - I use X as a reference to something which has a big VIRT, makes sense that has a big VIRT and its ok that it has a big VIRT (because it holds image buffers, and maps large chunks of memory from the graphics adapter). I'm saying that it makes no sense for software which is much less complex then X to take as much as X. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s What can explain huge VIRT size and small RES figure at the same time? I can offer several possibilities - I don't know which of these applies to Nautilus (or your other examples): 1. Software which only knows how to grow, but not shrink. ... All this unused memory wasted space in the swap, but doesn't waste RAM. My problem is not wasted RAM - its over-used swap. I'm aware of the problem with Firefox (and any Java program), so I wasn't going to mention them. I really hope that GNOME doesn't have that problem. 2. Programs which uses a lot of threads. GNOME programs are usually very light on threads. I don't see any reason for an applet to use more then a thread or two. 3. Programs which use a lot of shared libraries. Unless I'm mistaken, shared libraries are counted in the SHR section, which is relatively small for GNOME programs - less then 20MB. Assuming its not (2) or (3) - does it has to be (1) (programs that don't free memory) ? I was always under the assumption that GNOME programs are more in touch with the UNIX way of doing things (the one true way), and their programs would not suffer from the same issues as Firefox and Sun's JVMs. -- Oded ::.. What boots up must come down. -- Net Philosophies = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. Are you talking about a field that shows how much memory a task has swapped out ? I don't see where you can get that info - I only see VIRT, RES and SHR when I ps, top or (my favorite) htop. When I say that my system has swap swamped, I mean that running 'free' shows almost 0 in the 'free' column for the 'swap' record. -- Oded ::.. But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. -- Bruce Leverett, Register Allocation in Optimizing Compilers = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 16/01/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? In parallel to the other comments - I use GNOME 2.14.3 on Debian Etch on an Athlon XP 2500+ (a 1.1GHz processor) with 1.25Gb ram and can't remember when I last saw this system use its swap since I upgraded from 512Mb. I'm not saying this is an ideal situation, it still uses 47% of its RAM for programs (and the rest for cache) and it's still slow (I tend to blame the CPU and the old graphics card) but it's far from the situation people here describe about their GNOME performance. I mostly use Firefox, with Skype, a few gnome terminals (which I heard are notorious for memory leaks) and the occasional OpenOffice application, and currently my system is up for over two days (apparently had a power failure over the weekend when I was outside home). So whatever is your conclusion - this is just another data point that maybe the problem is not totally generic to GNOME but maybe you should look for some additional causes in your particular setup. --Amos
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
run top then press f and p On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. Are you talking about a field that shows how much memory a task has swapped out ? I don't see where you can get that info - I only see VIRT, RES and SHR when I ps, top or (my favorite) htop. When I say that my system has swap swamped, I mean that running 'free' shows almost 0 in the 'free' column for the 'swap' record. -- Oded ::.. But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. -- Bruce Leverett, Register Allocation in Optimizing Compilers -- Constantine Shulyupin Embedded Linux Consultant 054-4234440 http://linuxdriver.co.il/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 16 Jan 2007, Oded Arbel wrote: And can something be done about it ?? Don't run Gnome, run fvwm like me ;-) You want eye candy, you got eye candy. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 22:35 +1100, Amos Shapira wrote: On 16/01/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? In parallel to the other comments - I use GNOME 2.14.3 on Debian Etch on an Athlon XP 2500+ (a 1.1GHz processor) with 1.25Gb ram and can't remember when I last saw this system use its swap since I upgraded from 512Mb. I'm not saying this is an ideal situation, it still uses 47% of its RAM for programs (and the rest for cache) [...] and currently my system is up for over two days (apparently had a power failure over the weekend when I was outside home). I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. So whatever is your conclusion - this is just another data point that maybe the problem is not totally generic to GNOME but maybe you should look for some additional causes in your particular setup. I'm using a default Fedora setup, with hardly any locally compiled software (and none that is used on a day-to-day basis). From my experience with other installations, this is common to any modern Linux OS running a fully featured desktop (GNOME more then KDE, but I can't say that its not happening with KDE) for more then a week of uptime. -- Oded ::.. Show me a sane man and I will cure him for you. -- Carl Gustav Jung (1875-1961) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. This field is sometimes confusing, here is why: Logically, you would expect this field really shows whether your program is partially swapped out and how much. But the reality shows otherwise. Even the Swap used field shows 0, you will be surprised that SWAP field of each tasks show greater than zero number. So, what's wrong? This comes from the fact that top use this formula: VIRT = SWAP + RES or equal SWAP = VIRT - RES As explained previously, VIRT includes anything inside task's address space, no matter it is in RAM, swapped out or still not loaded from disk. While RES represents total RAM consumed by this task. So, SWAP here means it represents the total amount of data being swapped out OR still not loaded from disk. I see. I don't think SWAP is exactly VIRT - RES: for example, the sensors applet has VIRT 94MB, RES 15MB and SHR 8M, but SWAP is listed as 75MB. For most apps, it looks as if SWAP is indeed = VIRT - RES which, if RES includes SHR, seems to me to indicate that all the memory mapped to the task is either resident or swapped: which is consistent with my feel of the system where when the accumulated VIRT of all the processes about equals available swap space + dynamic memory then the system breaks. -- Oded ::.. Hey Mr. postman look and see, what you have in the bag for me. It could be a bomb or it could be a letter - it doesn't matter, things can only get better. -- 'When the rainbow comes' / Paula Cole = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How Can We Help to Make this Happen?
Hi Amichai,
IMHO what we have to offer to make this happen is to pool our collective
intelligence (or lack thereof) to start writing public policy.
The market will not correct itself in the short run because of the cost
benefit factors that the spokesperson from the TA municipality so
correctly cites. So the only alternative is to lobby for a public policy
on open source, and we are the only people who can write that policy.
In order for the policy to have a chance of being accepted it probably has
to be drafted as a requirement to follow international standards (ODT, W3C
HTML, etc..) in order to ensure equal access to all communities or
some such politically fashionable language. The place to apply this policy
is probably with the Bank of Israel, the Ministry of Finance, and finally
the Knesset itself. Our ally in this is probably ISOC-IL and perhaps a few
oddball academics.
If any of you are interested in puting some time and effor into this
please contact me off list.
- yba
On Sun, 14 Jan 2007, Amichai Rotman wrote:
Date: Sun, 14 Jan 2007 11:45:39 +0200
From: Amichai Rotman [EMAIL PROTECTED]
To: Linux-IL linux-il@linux.org.il
Subject: How Can We Help to Make this Happen?
http://netmag.nana.co.il/Article/?ArticleID=420657
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il -
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word unsubscribe in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. There are two kind of memory-leak-like problems in modern software: 1. Real memory leaks, where the program grows, and grows, and grows, the longer it runs. 2. The program not being able to shrink its memory use, and therefore each long-running program always takes the maximum amount of memory it needed up until now. (Every mathematician learned that sum(max(...)) max(sum(...)), which is why this is such a serious problem when you're running many programs). I can, if I try very hard, understand why some clock applet should take 10 MB of memory (because it uses inefficient overly-general libraries, because it has translations into 100 different languages loaded into memory, or who knows what). What I can't understand is when the memory of such a program grows over time, forcing you to reboot every week (like you said). About a year ago, I discovered a memory leak in my favorite window manager, ctwm: I noticed that after several months (!) of continuous use, it used up a few megabytes more than it used initially. I bit of debugging (with a memory leak-finding tool that I wrote) turned out that ctwm leaked a few bytes of memory for every new window opened. After you open tens of thousands of windows over a few months, this adds up to a few megabytes. I reported the bug, and it was fixed. Contrast this to more modern software, which leaks megabytes *every day* (if not every hour), and nobody is even trying to do anything about it... Alas... -- Nadav Har'El| Tuesday, Jan 16 2007, 26 Tevet 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |A witty saying proves nothing. -- http://nadav.harel.org.il |Voltaire = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Moodle in hebrew
Just installed moodle with the hebrew language pack (from the moodle site). I see that the RTL is not perfect and some strings are not translated yet. Is anyone still working on this? (I seem to remember improving the translation was a candidate for the Hamakor prize some years ago). Thanks, Micha = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Gnome has *footprint* for a logo - since forever, and for a very good reason. Somehow people don't get the hint until it is too late... -- Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Convince me to switch to Digikam (Was: Exaile - a Gtk+-based Amarok Clone)
Allright, I've got 0.9.0 installed! Needed to lay down some tarballs, but that's fine. Here are my comments, to those who are interested in them. Some of them will turn into threads on the digikam list, I'm sure :) Hebrew interface! Yay! Digikam doesn't seem to be much faster than F-Spot in scrolling through the photos. It also has quite a bit of lag. Even after rebuilding all the thumbnails, I can see them slowly filling up the screen (takes about 15 seconds) while scrolling pages. Also, switching to the one picture view displays the previous picture shown for a second or two. I can get used to it, but it is rather annoying. My IPTC data is shown only as X-box-X in Metadata-IPTC-Contact. That's rather usless as it's not assigned a tag. I'll take that issue up on the DigiKam list. Clicking on an image opens the editor, not the single-picture view. That's going to drive the wife nuts, she actually uses the mouse. As is typical of KDE, the interface is horrible cluttered. Buttons on the left, buttons on the right, buttons above. Sidebar on the right AND on the left! KDE 4 is supposed to address this, we'll see. Dotan Cohen http://essentialinux.com/source.php http://laurieotto.com = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 16 Jan 2007, Oleg Goldshmidt wrote: Gnome has *footprint* for a logo - since forever, and for a very good reason. Somehow people don't get the hint until it is too late... Yes ... the image is incomplete, it lacks an ideogram of the mouth in which the foot is placed. Peter (neither gnome nor kde) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Moodle in hebrew
Micha Silver wrote: Just installed moodle with the hebrew language pack (from the moodle site). I see that the RTL is not perfect and some strings are not translated yet. Is anyone still working on this? (I seem to remember improving the translation was a candidate for the Hamakor prize some years ago). A Moddle translation project asked for and got a grant from ISOC and then canceled partcipation for undisclosed reasons. An earlier non complete translation is what you've been using. Gilad = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007 at 12:47:03PM +0200, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. Actually it seems that KDE apps are reasonably efficient. Gnome uses Gecko as an HTML rendering engine and thus is not entirely off the hook regarding FireFox. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. If you use Konqueror and KMail there isn't much to gain from using fvwm as the WM (memory-wise). I tried using KDE recenly in a system with 128MB. Basically usable. Sadly kword is not usable enough and thus OOo has to be used, which is a loading and swapping pain. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849755 || friend t = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tuesday, 16 בJanuary 2007 12:47, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. Completely agreed. I think it's bound to happen Real-Soon-Now(tm) because of several factors: - Linux is penetrating some semi-embedded markets (think Nokia 770 and its successors). These require trimming classic desktop components. This means there are people which the knowhow and the time/budget to invest in this. (e.g: Mozilla -- Minimo) - Linux is accelerating in 3'rd world countries which use low end hardware. One interesting example is OLPC which already push various components of Fedora to trim down. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 But it does move! -- Galileo Galilei = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On the contrary to all said on this thread, I must admit that using KDE with 512 MB is quite sane. I am using this setup on a machine running Etch. kmail running for several weeks, same as akregator, Firefox 2 running on and off, konsole is usually open. The machine is very responsive a hour after I start using it every day (stupid debian updates take 20 minutes every other day, sometimes even 40 if I do not update several days). Uptime is ~60 days using a stock kernel (I actually took a kernel.org source and compiled it into *.deb, quite cool). I am also running OpenSUSE 10.1 on a very broken system (PS/2 connections does not work, and 2nd IDE is completely dead), this is why I don't have high uptimes on that machine. However, this machine has 512mb of memory, which serves me to run Firefox2, Mozilla, a full KDE desktop and all other goddies (I tried even Beryl, which I just did not like, I went back to kwin). I even run 2 X sessions on the same time: the stock SuSE desktop and the stock KDE 3.x (or 4.X) compiled from sources. Quite frankly, it works pretty good. I assume more patient is needed, but hey, nothing comes for free. Anyone else running KDE and feeling the same as me? I understand that gnome is not a pretty sight, but I would like to know what other people think of KDE :) ביום שלישי 16 ינואר 2007, 16:10, נכתב על ידי Nadav Har'El: On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. There are two kind of memory-leak-like problems in modern software: 1. Real memory leaks, where the program grows, and grows, and grows, the longer it runs. 2. The program not being able to shrink its memory use, and therefore each long-running program always takes the maximum amount of memory it needed up until now. (Every mathematician learned that sum(max(...)) max(sum(...)), which is why this is such a serious problem when you're running many programs). I can, if I try very hard, understand why some clock applet should take 10 MB of memory (because it uses inefficient overly-general libraries, because it has translations into 100 different languages loaded into memory, or who knows what). What I can't understand is when the memory of such a program grows over time, forcing you to reboot every week (like you said). About a year ago, I discovered a memory leak in my favorite window manager, ctwm: I noticed that after several months (!) of continuous use, it used up a few megabytes more than it used initially. I bit of debugging (with a memory leak-finding tool that I wrote) turned out that ctwm leaked a few bytes of memory for every new window opened. After you open tens of thousands of windows over a few months, this adds up to a few megabytes. I reported the bug, and it was fixed. Contrast this to more modern software, which leaks megabytes *every day* (if not every hour), and nobody is even trying to do anything about it... Alas... = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Reminder: Telux: Ori Idan on Running Linux on an ARM 7 Board on 21-January-2007
This is a reminder that the Tel Aviv Linux Club ( http://www.cs.tau.ac.il/telux/ ) will hear Ori Idan talk about Running Linux on an ARM 7 board on Sunday, 21-January-2007. The presentation will take place at 18:30, in Shenkar 222 (Physics and Astronomy building) in Tel Aviv University. More information can be found on the site: http://www.cs.tau.ac.il/telux/ The attendance is free and everyone are welcome to attend. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Tzafrir Cohen wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. They are not developed by Gnome or KDE, but they are based on the same monolithic if-we-take-up-a-lot-of-memory-the-users-will-just-buy-more philosophy. For the life of me I can't understand why XEmacs, the original kitchen sink that tries to do everything for everybody, takes memory in the order of 10-20MB, and OpenOffice often takes 10 times more. Actually it seems that KDE apps are reasonably efficient. Let's compare a few clock applications: app VIRTRES NOTE xdaliclock 3756796 oclock 36321540 xclock 85442976 kclock.kss 25840 8164 clock-applet (Gnome)90212 11256 (only the applet process) clock_panelapplet (KDE) 33664 12028 (for kicker with only a clock applet) This is nothing short of ridiculous. These integrated enviroments may be great for new users, but I can't for the life of me understand the justification of using so much memory for a clock applet. Even xclock's memory use surprised me, and it is just a third of what the KDE/Gnome applets appear to use. P.S. Offering some insight on why Gnome's VIRT figures are huge, which was the question that started this thread: Trying to understand where Gnome's clock-applet's huge VIRT comes from, I discovered something very interesting. It start with just 28 MB of VIRT, but at the moment you right-click on the clock, and a menu pops up, it grows to, belive it or not - 90 MB. That's 60 MB to show a menu !? I diffed the /proc/../maps, and this is what the extra 60 MB contain: 0.5 MB of newly allocated memory, plus a lot of mapped files; One interesting mapped file is the HUGE /usr/share/icons/crystalsvg/icon-theme.cache, taking up 28 MB of mapped space! But as I suspected, out of this 60 MB, most is read-only and mapped from files and thus takes up *zero* ram, and *zero* swap space. Other than giving a huge VIRT number, these mappings don't cause any harm. For the curious, here are the complete map diff, before and after I click on the menu: 0015a000-0015d000 r-xp 03:01 65215 /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so 0015d000-0015e000 rwxp 2000 03:01 65215 /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so 092df000-09431000 rw-p 092df000 00:00 0 092df000-094ae000 rw-p 092df000 00:00 0 b4056000-b40b6000 rw-s 00:08 19496969 /SYSV (deleted) b40b6000-b4bfe000 r--p 03:01 426187 /usr/share/icons/hicolor/icon -theme.cache b4bfe000-b6745000 r--p 03:01 848001 /usr/share/icons/crystalsvg/i con-theme.cache b6745000-b6e9b000 r--p 03:01 1630568/usr/share/icons/gnome/icon-t heme.cache b6e9b000-b7c2f000 r--p 03:01 1026257/usr/share/icons/Bluecurve/ic on-theme.cache b7c2f000-b7c3d000 r--p 03:01 2347542/usr/share/icons/Clearlooks/i con-theme.cache -- Nadav Har'El| Tuesday, Jan 16 2007, 27 Tevet 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |This box was intentionally left blank. http://nadav.harel.org.il | = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Hi, I am using GNOME-2.14.3+ desktop, all compiled from sources on a linux system, all compiled from sources with gcc-CVS-200608XX, using -march=athlon-xp on Athlon 2600+ (1917 MHz) with 256 MB RAM. I have experienced the GNOME memory usage problem before glibc-CVS-20060813. After upgrading glibc to that version, total memory usage have dropped below 82 MB, swap usage is 0 to ~200 KB. I am looking at xosview screen. I am running LyX (using pdflatex), Firefox, Inkscape, evince, java. I do not run GNOME clock applet, which runs full evolution-data-server. The system is very responsive, - Moshe Gorohovsky Tzafrir Cohen wrote: On Tue, Jan 16, 2007 at 12:47:03PM +0200, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. Actually it seems that KDE apps are reasonably efficient. Gnome uses Gecko as an HTML rendering engine and thus is not entirely off the hook regarding FireFox. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. If you use Konqueror and KMail there isn't much to gain from using fvwm as the WM (memory-wise). I tried using KDE recenly in a system with 128MB. Basically usable. Sadly kword is not usable enough and thus OOo has to be used, which is a loading and swapping pain. -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
