K.Mandla's blog of Linux experiences

Good but bad: Slitaz at 150Mhz, 32Mb

The good news is, I have a working, installed Slitaz system on the Mebius, which is very gratifying. The bad news is, unfortunately, it runs like a dog.

Before I go any further, I want to be very clear that I love Slitaz almost as much as life itself (okay, maybe that’s hyperbole), and I don’t hold it in any lower esteem because it’s sluggish at 150Mhz on 32Mb of memory. And I don’t just say that because the devs sometimes read these pages.

No, Slitaz is excellent, excellent stuff. If I were to create my own distro, I would want it to turn out just like Slitaz. In fact, one of the reasons I don’t build my own distro is that Slitaz is around, and I see no reason to duplicate efforts.

A few months ago I was having issues getting a working system installed, and even now that I have one in place, performance is sub-par. Personally, I think there are two reasons for that.

First, the graphical environment is a bit high-end for a Pentium with an ancient VESA1.2-driven Trident video card. Graphically speaking the machine is taxed anyway, but anti-aliased fonts and rollover effects and just opening a right-click menu can be highly stressful.

That’s also why I don’t have a screenshot of the system at work: It takes more than 30 minutes for the process to start.😯

To add insult to injury, 32Mb is still too low for a working Slitaz system, and I say that with the deepest respect for what is an amazing, efficient, ultralight system.

But moving the pointer, triggering a menu, pausing for a tooltip — all of these cause huge spikes in processor strain. Actually triggering a menu causes swapping for two or three minutes while it thinks through the processes, and finally opens a password box.

Sometimes it’s even hard to shut down the machine, because the system has to swap for four or five minutes to the get the dialog box open, before I can tell it to shut down. It’s easier to just turn it off and hope for the best.

I should say that I’ve tried both the full version of the cooking ISO, and the low ram, CD-based image which I understand requires less memory but more optical drive access.

And I’ve installed both systems via virtual machine and written them across from USB thumb drives. The low ram system seemed slightly more perky, but that might have been my imagination.

And I should say one more thing — that the Slitaz systems I installed a long time ago on a 100Mhz, 16Mb system were equally overburdened. So the added 50Mhz and 16Mb aren’t helping that much. It’s just not enough hardware.

On the other hand, it might be worth the time it takes to build up from a console-only Slitaz system, and sculpt something sparse. I have great faith in Slitaz; this might be the route to take.

If I can find some time, I will add it to my to-do list. That list is already quite long though. …🙄

Post navigation

15 thoughts on “Good but bad: Slitaz at 150Mhz, 32Mb”

I am experiencing basically the same issues as you describe, but wanted to try it anyway, due to the small amount of HDD it requires.

In my case (500MHz CPU, 96Mb RAM) only 2.0 loram LiveCD got up and running, but then I just upgraded to 3.0, and still the base system used “just” 30 MB RAM.

My next step (I`m still on it) was going to reproduce the minimum install you previously described on “How little it takes”.

How about Puppy Linux? Have you tried it under 30Mb RAM? It’s meant to be lightweight, it booted quite well to me, and it leaves a small footprint as well, plus there are some tools around that might be helpful in order to use drivers and packages from other distros if needed.

Puppy is on the list; I have a system waiting to copy and test, but the time it takes to transfer these things over USB1.1 and then troubleshoot them means I sometimes need the better part of a day to get to a working state.

Thanks, I’ll be very interested to see what you can come up with. It might be like the comment above suggests, that a sitting system rides around 30Mb, and so a computer with only 32Mb starts paging immediately.

It might require a completely different approach to a desktop though; I can tell you that very sparse console systems on Xorg, for the same computer, usually need about 10Mb on boot. But those use no graphical interface and are usually Awesome or Musca desktops.

As one of Slitaz developers, first of all, congratulations, and second, is there any documentation explaining how you get all the programs to take so few resources?

I find it quite an interesting subject but, after looking here and there, I didn´t get to know which documentation I could start from if I wanted to, let´s say, strip down packages from other distros the slitaz-way.

Maybe it´s just that I am rather bad on understanding the documentation you give, but any idea would be very much appreciated…

PS: What I actually have in mind is to put Slitaz and arch together, as a rolling-release distro, which could work under 128 RAM and 1Gb HDD

It sounds familiar. It’s not that I have to wait for 30 minutes, but it’s very slow (compared with D.S.L.). My testing oldie is a low-class pentium 2 with 384mb, so I guess it’s not (only) a memory thing.