[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Clients with 64MB of RAM

Hash: SHA1

On Jan 11, 2010, at 9:39 PM, Barry Cisna wrote:


When you say Fedora12 ,I assume you mean K12linux/LTSP5?
Yes I am.

64MB will never come close to being enough ram for ltsp5. 128mb on the
TC is not enough realistically.
I'd say 128 MB is the new minimum for LTSP 5. Or, more accurately, LTSP 5 as implemented on newer versions of fedora. I guess I don't expect them to get it working on 64MB clients, I'm just hoping my GX1s aren't about to become unusable in Fedora 13 or 14.

Just an FYI: I found the following,and this does not mean anything other than a baseline. I merely done to this to try and determine why ltsp5 is
so much more memory intensive than ltsp4.x.

My Ebox2300/128MB will work( but not really usable) on LTSP5 but takes
almost 4-5 minutes to boot up.
My GX1s only have 128MB but they seem to boot much more quickly

On ltsp4.x it takes about 30 seconds to boot to login screen,and works
great on anything you throw at it(Even Youtube and any video format).
Wish I was smart enough to understand what the underpinnings of LTSP5
makes it so much more a memory pig as compared to ltsp 4.x?
The bootup,PXE is the same protocol for both so my guess is 'just the
kernel' has more voodoo thrown into it that causes the overhead for the

From what I can tell, the additional burden of LTSP 5 comes mostly from using the distro's own build tools, and a tiny bit from things like increasing the size of existing code or new LTSP features. LTSP before version 5 was essentially it's own mini-distro and it contained the minimum amount of software needed to boot up a thin client and get and working X session and stuff like sound and local devices. You could add it into any distro by putting it in a folder, exporting it as a read-only share (NFS usually) and setting up the needed DHCP/TFTP/NFS services plus some other optional ones. K12LTSP did this work for us and also bundled useful education apps. But maintaining a distro was a lot of work and the LTSP developers didn't feel they were adding a lot of value. They had to spend a lot of time on things that every distribution works on, and had much less time to work on the LTSP specific code. Thus with LTSP 5 they moved to a system where they only maintain certain LTSP specific code and each distribution has to integrate LTSP. Basically, the tradeoff that LTSP made was to make running local applications, sound, and supporting more hardware easier. But at the cost of requiring beefier clients. Whether you like this tradeoff depends on your pool of old clients that don't work well with LTSP 5 and your desire for the features that LTSP 5 added.

Take Care,
Barry Cisna

K12OSN mailing list
K12OSN redhat com
For more info see <http://www.k12os.org>

Version: GnuPG v1.4.7 (Darwin)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]