Salix Forums

I understand no formal benchmarking was done to establish exact resource requirements and performance of Salix LiveCD.
My testing to have some rough idea to narrow requirements down was using Thinkpad 23 with 256M and 512M ram and comparing to vector and Zenwalk 5.2 (IMHO the sast one really good one):
- With 256M Salix 13.1.1 boot takes extremely long time. Eventually it finished and I was greeted with desktop. Zenwalk 5.2 live booted taking a normal exceptable time. Vector 6.0 Live (Both Lite and KDE also booted successfully in about their regular time).
- With 512M ram Salix boot was quick, just slightly longer than Zenwalk 5.2 and Vector
- When booted and fully up, Salix shows 140M-160M usage (HTOP). This was slightly more than Zenwalk 5.2 (about 110M), Vector Lite (about 80M) and Vector KDE (130M)
My question would be what accounts for Salix resource requirement to be significantly higher than Zenwalk 5.2 and Vector (Even higher than its KDE edition)?
Understandably Salix has far better application selection than Zenwalk or Vector, but in this case this should not impact resource requirement if they are not loaded...

Well, a few things come to mind very quickly. Zenwalk 5.2 is >2 years old and Vector 6 is >1.5 year old now. I don't really know about Vector, but at least Zenwalk 5.2 live used a gzip compression for the live modules, while all salix live releases use lzma compression which is a lot more efficient, but also a bit slower during decompression. The kernel has probably become heavier because it supports a lot more devices now that it did back then. There is also the matter of kernel compilation options; if I compile a kernel that supports limited hardware, it's going to be lighter than one that supports more hardware. All other software has evolved too, including important system software like Xorg and GTK+2, and evolution in software usually means more features, which in turn usually means more resources are needed.

Having said all that, I don't really agree with your way of measuring how light an OS is based on RAM usage. If anything, in an ideal system, I would prefer my RAM to be filled to 100% all the time. That means more information is stored into RAM, where it can be accessed a lot faster than it would if it were to be loaded from the hard drive. If the OS tries to free RAM when there is actually no need for RAM to be freed, then there is less information stored in RAM and the system needs to access that information from the considerably slower hard drive a lot more often, resulting to a significantly slower system overall.

Greetings Gapan,

Thank you. The reasons you provided do explain this gap in resource requirements.
An I do agree on filling memory and releasing pieces when needed, which leads us to run completely in memory approach with today's memory capacity on new computers...