Re: low RAM usage (plans: XDMCP/LDM/...

On Sat, Mar 22, 2008 at 08:11:35AM +0900, jam wrote:
> LTSP5 should be the shining best way to impliment TCs and not be
> crippled by lofty goals of trying to use pentium and 16M etc.
> It supports all the latest hardware, does fancy local media,
> sound etc etc. WOW

WOW.  Indeed.  Ten years ago a 486/16M would be my workstation
with *local* apps like gimp.  I won't settle for 486 but we do
run on 16M with ease by simply not using the feature which gives
us nothing special by itself, and disabling another (USB storage
run-time detection -- simply put, stopping udevd after initial
/dev population) which is unlikely to be physically connected
off motheboards of that epoch.

JFYI, Linux kernel scales better up *and* down today.  With a
"wow" mindset, it probably wouldn't enjoy the unexpectedly useful
low-end inspired features at high-end (e.g. saving energy in
datacenters due to notebook efforts).

> LTSP4 should be used for old hardware, small RAM, and the
> resulting loss of functionality.

Thanks, I've had my share of fixing that.
It's hard to recommend underquoted scripts.

> The fact that LTSP4 is no longer supported means your

Hm.

> developers ARE NOT INTERESTED IN THE KRAPPY HARDWARE side of
> town with a 2.4 kernel etc etc.

I think it's no longer supported because it's an obsolete
iteration, not due to "hardware side" or even "missing features".

On the next iteration, features were added (or replaced), but
some got lost.  And not everyone is happy to throw away hardware
that works perfectly today just because you call it "krappy".
You and me might actually run crappier hardware these days.

So I merely suggest the next iteration to be integrative,
and to much extent it is anyways (distros merging up).

> LTSP4 does exist and can deal with old HW. Lets not spoil
> EVERYTHING by being greedy trying to fit LTSP5 into a box
> where it does not fit.

It's not greed, it's simple "hey we can do it again!"
[and include those who got unintentionally excluded]


Lulling yourself into "resources don't matter" dream reminds
me clearly of an anecdote about people who were asked to tell
programmatically whether a natural number was odd or even.

A mathematician would suggest dividing by 2 and taking the
remainder.

A programmer would suggest taking the least significant bit.

A Microsoftie would suggest creating two tables in MS SQL,
one for odd numbers and another for even, and then simply
look where the particular number lands.


(it's not to say that anyone should optimize for ucLinux and
80386 hardware but there are lots of older pentium boxes supplied
via donations to schools in other countries, probably in yours
too; I'm yet to see them buried under garbage dualcore systems
since everyone upgraded to super-energy-efficient stuff)

> Telling one of [our] your developers that his work is krappy
> because it won't work with limited resources is really stupid.

Depends on the limit, on development stage, on what is actually
proposed.

I'd punish myself for e.g. an attempt to go 12M (useless) or
386 (all dead, way too slow).  But 16M were quite easy (a day's
experiment among the rest), and any extra megabyte helps bringing
stability and performance (so you don't actively swap over the
net) even when you've got generous 64 megs on a powerful P!!!.

> We choose MooKow

MueKow ;)

> because of the benefits, but there are costs too. c'est'la vie

I almost chose to roll my own 1.5 years ago, after reviewing 
LTSP4.2/5 and ThinStation.  Still decided that it would be better
in the long run to work with the team, not start yet another one.

If you don't see the benefit of pluggable infrastructure, or
if you're happy to upgrade hardware since centralization alone
would justify that -- fine.  Hope you'll still let me differ
(and to merge or at least propose things hopefully next week).

-- 
 ---- WBR, Michael Shigorin <mike-u2l5PoMzF/[email protected]>
  ------ Linux.Kiev http://www.linux.kiev.ua/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net