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

Michael Shigorin wrote:
> On Fri, Mar 21, 2008 at 11:18:34AM +0530, CyberOrg wrote:
>>>  > Don't know about RAM, I am able to boot PC with 128M ram fine,
>>>  And we're able to boot in 16M with pulse enabled. ;)
>>>  Production ISO images happily run clients with 24M RAM.
>>>  32M is a synonim for "Pentium MMX" largely, while
>>>  16M is a synonim for "Pentium".
> 
> (as 8/12M is synonim for 486 and ALT Linux is i586-optimized
> for ages, we're not going to spend any time to go any lower,
> that'd be a waste)
> 
>> Whoa! I I don't think we'd be able to get our current
>> implementation to boot on 16MB. Last thing that boots on 16M
>> ram is ltsp4.2. We might barely be able to do with 64M ram, I'd
>> be happy if it does that.
> 
> Well I told ogra quite a while ago on IRC that I consider ruining
> what worked in favour of some specific Ubuntu development goals
> is a Bad Thing(TM)... guess there was some management/project
> pressure to introduce encrypted auth asap and at any price,
> including pissing off schools with heaps of older hardware in
> favour of callcenter deployments with new "thin" clients...
> 
> 
> We're planning to do some rework to be able to switch transport
> which a thin client uses to communicate with a server: we're not
> seeing the need to drop XDMCP and NFS root, and we're not seeing
> any immediate improvement in going LDM/squash (things are better
> but way from being on par with where they were years ago to me).
> 
> As different folks and deployments even of a single LTSP-enabled
> distribution release might have vastly different (and conflicting)
> requirements, it seems natural to support:
> 
> - NFS/squash on the "get-it-to-netboot" side, and
> - XDMCP/ldm/[probably NX/...] at "get-it-to-login-and-work"
> 
> to cover both new and old terminal and networking hardware,
> and take the sensitivity to wire snooping into account while
> not forcing everyone to pay for someone's concerns.
> 
> Ideally, that would also enable one TC pack or subnet to use one
> combination, and another to use another, but "ideally" comes
> after "practically", even if we should keep that in mind, eh?
> 
> 
> So for our (almost) current implementation, we just dropped
> ldm with squash and pulled in those things that we considered
> practically superior from LTSP4 (while keeping the plugin
> infrastructure and general cleanup approach of LTSP5).
> The result is that what we want to work does work.
> 
> The next step for us is to bring things into mergeable shape
> (last time we sorta did, the "re-upstreamization" kicked in
> and I had to postpone that).  So, er, I hope again to get done
> with that RSN :) and move on to what was described above.
> 
> Hope that such multiway approach is acceptable to others who
> are interested in LTSP, and that "one true way" was a temporary
> trouble.

I like this approach VERY MUCH.   While I really like what Ollie and 
others have done with LTSP-5, I think it's a mistake to forget about the 
  older, slower (and even newer slower) hardware that exists.

For years I've considered that LTSP is a collection of technologies that 
provide thin client functionality to Linux based systems, rather than 
just a single method.

Jim McQuillan
[email protected]


-------------------------------------------------------------------------
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