[K12OSN] Project MueKow

[Les Mikesell]

On Tue, 2005-03-01 at 15:38, Jim McQuillan wrote:

> A huge number of LTSP users are deploying with 486's, Pentium-I's and
> Pentium-II's, with 32mb (or less).  Trying to use the servers optimized
> binaries just wouldn't work in that case.  and at this point, we're just
> not interested in having to maintain 2 different ways of doing this.  1
> for same-arch clients, and a separate method for different-arch clients.
> and when I talk about diff-arch here, i'm referring to the difference
> between i386 and i686.  (Lots of i386 clients running from i686
> servers).

OK, server disk space is cheap enough that it probably isn't worth a lot
of trouble to save space by making the NFS-export the same as the server
uses.  However, just based on hardware that has been manufactured and
is now obsolete and going off-lease, I'd guess that there is an
excellent chance that anyone building a new ltsp system today (and for
a long time going forward) would end up with an all-686 system). Thus
I'm not sure it makes sense to double the work needed to maintain
a same-arch system just to keep it symmetrical with multi-arch. 
However, being able to push the server binaries into the client
image with a script instead of having to run another update from
a client would take care of this objection (and I think the stateless
project does something like that).

> Once we get past our experiment, we certainly could decide to open it up
> to use the servers actual binaries for clients that can support it. But,
> for now, we really need to keep the pre-i686 clients in mind.

Of course, but the mechanism for any arch that doesn't match the
server should permit this for those who need to do that extra work - and
this should allow the exported image to live somewhere other than the
ltsp server.  You should be able to have one good file server holding
home directories and multi-arch system exports for any number of ltsp
servers and thin/fat clients.  In this scenario it would be easy to
also network-boot the ltsp servers.

> You've got some other great ideas too, but I think we've got to take
> this one step at a time, and make sure we are at least as good as the
> current LTSP.  Then, once we've accomplished that, we'll see where we go
> next.

I'm not sure there is a one-step-at-a-time way to get from the current
LTSP to one that permits arbitrary mixtures of thin/fat/in-between
clients which seem to make sense according to hardware logistics. Making
the stateless or knoppix network boot mechanisms accommodate starting
with 'X -query server' for low-powered boxes looks like it should be
easier.  The reason I'm making this argument now is to help avoid the
'2 different ways' problem you mention above, but for fat vs. thin
clients when we know that available clients are getting fatter.

-- 
  Les Mikesell
    les at futuresource.com