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

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.

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