- This topic has 96 replies, 18 voices, and was last updated Jul 13-12:05 pm by Brian Masinick.
-
Posts
-
Brian Masinick
As the antiX distro is positioning like lightweight system for old or weak computers, then, I think, it should no have any DE’s by default. WM’s are quite enough. But some DE’s should be ready-to-install via Package Installer for whom who has relatively powerful computer and/or who like DE’s.
I agree with you. If we’re going to have more distributions of different names though, like MX Linux for Xfce, that’s fine.
I’ve used antiX Core and antiX Base in the past to put together alternative systems. I built one a long time ago using a reasonably light implementation of Xfce that ran a little like MX Linux, though mine may have been even lighter because I only installed the minimal Xfce configuration, then added only the applications that I actually use. Given that MEPIS once had a reasonably light implementation of KDE, MX Linux has a light implementation of Xfce, and both the aged LXDE and the more current LXQT don’t require huge amounts of memory as long as you install and configure only what you actually need and use.
My guess is that most desktop environments, stripped to the basics, probably consume between 200-400 MB before adding applications; most of them should be able to beat the 400 MB number. Window Managers, a single component, do not use that much memory. I’ll come back with a few numbers from some observations.
--
Brian MasinickBrian Masinick
Lubuntu with LXQT uses 418 MB on my Dell Inspiron laptop running only a Qterminal with a “top” command. With the terminal and ps ax | wc -l it’s running 167 processes.
MX Linux uses slightly more memory, 419 MB, running quite a few more processes. The ps ax | wc -l indicated 194 processes.
--
Brian MasinickBrian Masinick
Debian Sid with a light Xfce is one of the best with a light DM: 296 MB of memory with only 68 processes started.
Peppermint 10 is in between with 359 MB and 84 processes.
Of course when you only use a Window Manager we’ve had several people report memory usage around 145 MB. MANY years ago I was looking at memory usage on antiX with various window manager setups. Back then IceWM used the least memory at an excellent 58 MB. Most of the other small window managers I tested with antiX used around 62 MB, so the kernel and tools have grown quite a bit since that time (a few years after the original antiX!
- This reply was modified 2 years, 10 months ago by Brian Masinick.
--
Brian Masinick
mroot
I think the developers at mozilla, the mate project, etc. do care about ram usage and cpu load. But their perspective is a bit different from members of our forum. They are building software that is targeted to run on new hardware, five year old hardware and to a certain extent 10 year old hardware. That hardware is going to in most cases have 4 gigs of ram if older and/or consumer grade. If it’s enterprise grade it’s going to have 8 or 16 gigs of ram, i5 or better processor and maybe have a ssd as well. So if firefox runs well on a Mate desktop loaded on hardware that has 4 gigs of ram they are satisfied and so are their employers. If on the other hand if it requires 20 gigs of ram to run properly they’re in big trouble.
I don’t think we have had a DE edition in the past but I don’t see a problem with having a separate iso with a DE rather than a Window Manager. I think I will probably stick with fluxbox but I can see how others might want something heavier. It may also attract users that we don’t currently have who wouldn’t have any exposure to antiX or to window managers in general.
olsztyn
I don’t think we have had a DE edition in the past but I don’t see a problem with having a separate iso with a DE rather than a Window Manager. I think I will probably stick with fluxbox but I can see how others might want something heavier. It may also attract users that we don’t currently have who wouldn’t have any exposure to antiX or to window managers in general.
I completely agree. I will continue leveraging my current antiX instances, so laboriously put together and debugged and based on IceWM and Fluxbox for some time in the future. However I am also looking forward to the new DE based antiX, whatever DE is going to be chosen by antiX owner. I will gladly use it if not heavy on resources and equally capable of Live version as current antiX.
Retaining full Live capability is critical here. Resource heavy and Live do not agree with one another too well, so much of the advantage of current antiX is being lean. If the new DE is too heavy that would kill much of Live advantage…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersBrian Masinick
For those of you who have not tried it, MX Linux runs quite well from a USB, nearly as well as antiX and it has similar technology and tools, just Xfce instead of IceWM and Fluxbox.
In the past MEPIS ran excellent from media too.
--
Brian MasinickAnonymous
Brian Masinick
Another “suggestion” in the meantime for those of you who want to try out other desktop environments (or other window managers).
The Package Installer has a section entitled Desktop Environment and another one called Window Managers.
For those of you with the resources and the creative spirit, you can “Create Your Own” antiX ‘spin’ with the environment(s) of your choice. If you want additional window managers, you can install them yourself from either apt or synaptic.
Here are a few that I found available:
9wm – X11 window manager inspired by Plan 9’s rio
aewm – minimalist window manager for X11
aewm++ – minimal window manager written in C++
afterstep – window manager with the NEXTSTEP look and feel
awesome – highly configurable X window manager
blackbox – Window manager for X
bspwm – Binary space partitioning window manager
byobu – text window manager, shell multiplexer, integrated DevOps environment
clfswm – A(nother) Common Lisp FullScreen Window Manager
ctwm – Claude’s Tab window manager
cwm – lightweight and efficient window manager for X11
deskmenu – A root menu for X11 window managersThere are PLENTY more to choose from for the ‘truly adventuresome’; this is not even a COMPLETE list!
CHOICE! That’s what the free and open software environment offers. Just because we don’t include it directly in antiX DOES NOT prevent the inquisitive and experimental student of software to go hunting and try out various alternatives. Regardless of what we do with the base or full packaging of antiX, please know that you can build any of these yourself with the tools that are already provided for you. Best wishes as you customize your system in the ways YOU prefer!
--
Brian MasinickThis is exacly what I just found out searching for ways to reduce RAM on Mate. The funny thing is that they convince their users of the same idea. An answer I found on manjaro forum for someone asking how to reduce RAM consumption for Mate:
Why do you want to lower it? Are you having issues with running out of RAM?
…
Unused RAM is wasted RAM.
If you want to save RAM, physically remove it from the computer.Now I know why MATE didn’t start reducing memory leaks untill version 1.22. People didn’t care.
Thanks for highlighting this problem! This is what worries me. It worries me that such not carrying users contribute to perpetuating development of junk software, not caring about memory waste nor leaks and arguing that memory is abundant and cheap. From my observation current antiX (IceWM or Fluxbox) is (thankfully) pretty much behaving well in terms of memory leaks.
Some of my rudimentary observations:
– Initial memory used by antiX, before starting anything will naturally jump significantly after starting major memory demanding app such as browser.
– After shutting down such browser memory used goes down, although not all the way but reasonably close. Eventually it decreases further, almost to the initial value. This can be repeated and I do not see a significant memory use drift with current IceWM and Fluxbox based antiX.
– If DEs cause memory leak on top of very high memory requirements up front that would compound a problem for antiX DE version.
As my understanding is the current DEs provided in antiX via package install are just experimental implementations. I suspect used memory measurements for them could be significantly skewed and in reality, when it comes to real implementation of DE antiX the results could be much better.
So, since I should not draw conclusions on current antiX experimental versions of DEs, I did the same as above rudimentary test for Gnome and KDe in Intel’s Clear Linux and my measurements (on the same machine):
– Initial memory use with Gnome = 510M. After starting Chrome jumps to about 720M. After shutting down Chrome it (immediately!) goes back to 510M. Performs so repeatedly.
– Initial memory use for KDE-Plasma = 645M. After starting Chrome it jumps to just about 900M. After shutting down Chrome it (immediately) goes back to 645M… Performs repeatedly.
From the above rudimentary test: Does this mean that Gnome and KDE may not have inherent memory leaks, at least as they are properly implemented?
Just my two cents…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersBrian Masinick
This is exacly what I just found out searching for ways to reduce RAM on Mate. The funny thing is that they convince their users of the same idea. An answer I found on manjaro forum for someone asking how to reduce RAM consumption for Mate:
Why do you want to lower it? Are you having issues with running out of RAM?
…
Unused RAM is wasted RAM.
If you want to save RAM, physically remove it from the computer.Now I know why MATE didn’t start reducing memory leaks untill version 1.22. People didn’t care.
Thanks for highlighting this problem! This is what worries me. It worries me that such not carrying users contribute to perpetuating development of junk software, not caring about memory waste nor leaks and arguing that memory is abundant and cheap. From my observation current antiX (IceWM or Fluxbox) is (thankfully) pretty much behaving well in terms of memory leaks.
Some of my rudimentary observations:
– Initial memory used by antiX, before starting anything will naturally jump significantly after starting major memory demanding app such as browser.
– After shutting down such browser memory used goes down, although not all the way but reasonably close. Eventually it decreases further, almost to the initial value. This can be repeated and I do not see a significant memory use drift with current IceWM and Fluxbox based antiX.
– If DEs cause memory leak on top of very high memory requirements up front that would compound a problem for antiX DE version.
As my understanding is the current DEs provided in antiX via package install are just experimental implementations. I suspect used memory measurements for them could be significantly skewed and in reality, when it comes to real implementation of DE antiX the results could be much better.
So, since I should not draw conclusions on current antiX experimental versions of DEs, I did the same as above rudimentary test for Gnome and KDe in Intel’s Clear Linux and my measurements (on the same machine):
– Initial memory use with Gnome = 510M. After starting Chrome jumps to about 720M. After shutting down Chrome it (immediately!) goes back to 510M. Performs so repeatedly.
– Initial memory use for KDE-Plasma = 645M. After starting Chrome it jumps to just about 900M. After shutting down Chrome it (immediately) goes back to 645M… Performs repeatedly.
From the above rudimentary test: Does this mean that Gnome and KDE may not have inherent memory leaks, at least as they are properly implemented?
Just my two cents…Given what you are observing, it at least indicates that the environments you used do not have “rampant” memory leaks; it is not a guarantee that there are zero memory leaks or defects, but most systems do work on getting rid of issues of this kind, so I’d say these systems are likely to be very solid.
--
Brian MasinickBrian Masinick
I would add that if your system runs well and has enough memory to avoid swapping and the overall performance is acceptable, don’t worry about it.
We don’t all have great new hardware though, and so we DO try to keep some of the antiX variations as lean and efficient as possible.My Dell Inspiron 5558 laptop ran any and all workloads quickly and efficiently when it was new. Today it still works, but I’d say that CPU, memory, and disk utilization DO matter for me, and it’s not that they are all FULL; they’re not. I rarely if ever swap, yet the response is not necessarily what it once was.
Chances are my disks are fragmented to some extent, but whatever the cause, performance DOES matter. If I could just run out and buy a $2000 system that would be great. Since I am retired I don’t want to do that until absolutely necessary. For me, I won’t be running the desktop environment software very often, and if I do it’s the lean ones that aren’t too heavily configured; they at least work for me without waiting 5 minutes for simple operations.- This reply was modified 2 years, 10 months ago by Brian Masinick.
--
Brian Masinick
Xecure
Sorry to have brought confusion to the thread. My comment
Now I know why MATE didn’t start reducing memory leaks untill version 1.22. People didn’t care.
is an exaggeration. Of course bug fixes for memory leaks were done on previous versions of MATE, but were not as sought out until version 1.22. All previous versions have had many memory leaks fixed, it is just that the priority was porting libraries, adding features, etc. In comparison with the version 1.22, all others seem to have less emphasis in the mem leak aspect.
It was not my intention to discredit the MATE development team. They work hard, but as all devs, they have their priorities.Please forgive my exaggerated claims as they sparked from reading comments on the internet. Though I may dislike a distro/DE/environment, it doesn’t mean I should badmouth them as I did in the above comment. They spend a lot of time and effort to bring something functional to life for many to enjoy for FREE. As a user, I should consider all their hard work instead of simply dismissing it like that.
Once anticapitalista decides a path, we will then test it out and see what we can contribute to it.
Again, sorry for the confusion and sparking a debate based on me giving misinformation.
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Brian Masinick
To Xecure:
Yeah, words can be easily misconstrued. Thank you for amending your comments.
For me, for whatever reason, I have never been a fan of GNOME desktops, though there is plenty of good software. It’s personal preference, nothing more.
Back when Xfce, KDE and GNOME were all much younger, I used mostly KDE at first but moved to Xfce (actually before they changed from the library they used in the early days); I forget which GUI Library they used, but they later moved to the Gtk+, so it shared this with GNOME.
I think that I liked the greater flexibility in KDE and Xfce. Today I use Xfce instead of KDE but still rarely use GNOME, call it “user preferences).
In keeping with the user preferences, my bias when using antiX will be to primarily use the light footprint stuff. When I want a desktop I feel that MX Linux does a great job. I don’t oppose offering other environments, it’s just that I may not actively test or use all of them since I have more than enough great software to use now.
Freedom of choice says to pursue the things that we love so I encourage the community to work on and explore. Just because one person isn’t into it should not discourage anyone else.
I love the diversity of what this community offers! Let’s keep having fun and exploring cool software! 👍📯🎶🎵
--
Brian MasinickOf course bug fixes for memory leaks were done on previous versions of MATE, but were not as sought out until version 1.22. All previous versions have had many memory leaks fixed, it is just that the priority was porting libraries, adding features, etc. In comparison with the version 1.22, all others seem to have less emphasis in the mem leak aspect.
It was not my intention to discredit the MATE development team. They work hard, but as all devs, they have their priorities.Thanks Xecure for clarification and more detail…
Just to emphasize, personally I have nothing against MATE if such memory leak issues are fixed by now. In fact I have absolutely no preference of any DE if it satisfies my requirements mentioned earlier and whatever DE will end up being chosen by antiX owner I am fine with such choice, as I can easily adapt to different their ways.
However for DE as well as any other piece of desktop infrastructure first and utmost priority and responsibility is solidity and integrity, to make sure it behaves correctly. Any adding of features, etc., should be second priority, after first priority has been accomplished.
Perhaps understanding of such principle and adhering to it is not that common in Linux world, what could the the result of attitude of users who just do not care about quality of infrastructure as long as it (kind of) works for them with the DE they are familiar with.
Just my two cents…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersWe don’t all have great new hardware though, and so we DO try to keep some of the antiX variations as lean and efficient as possible.
Yes. And I hope antiX will continue to be lean (as much as practical) even with the new DE edition. Whichever DE it will be chosen however, it should not be leaking memory in addition to modest resource requirements.
I am not sure if such responsibility of cleaning up memory used by application such as DE relies solely on DE, however. Perhaps this responsibility is partly on the OS. Excellent results of no leaks for Gnome and KDE was from tests performed on Intel’s Clear Linux, which has reputation of being rock solid. I am curious of such results performed on other (much less solid) distros, such as Ubuntu…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
- You must be logged in to reply to this topic.
