[K12OSN] Project MueKow

[Jim McQuillan]

Les,

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

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.

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.

Thanks,
Jim McQuillan
jam at Ltsp.org



On Tue, 1 Mar 2005, Les Mikesell wrote:

> On Tue, 2005-03-01 at 12:14, Jim McQuillan wrote:
>
> >      http://wiki.ltsp.org/twiki/bin/view/Ltsp/MueKow
> >
> > Please read through it, and give us some feedback.
>
> If you are going to make this kind of change, why keep the
> /opt/ltsp/i386 copies at all, at least for machines of the
> same CPU type?  Why not boot all clients as though they would
> run as fat clients, mounting the native binaries from the host but
> on the weaker ones continue to run the desktop remotely?
>
> http://fedora.redhat.com/projects/stateless/ seems to be on the right
> track although they seem a little carried away with duplicating a
> snapshot image for the clients to run instead of mounting the live
> server binaries (hasn't Solaris offered that for ages?).  Why not
> back a thin-client startup (X -query server) into that framework,
> leaving the option to run anything you want as a local app on any
> client?   Knoppix also has a workable client-boot configuration
> although they obviously have already had to deal with the distribution
> image being mounted read-only.
>
> For a P300 and up, running a local desktop starts to make sense.
> The 'windows years' have left us with tons of obsolete hardware designed
> to run a desktop and commodity-priced servers that can only handle 30
> or so clients.   If your goal is to recycle the clients it makes sense
> to take advantage of their power to reduce the need for new servers by
> running the desktop and/or some apps locally.  If you network-mount the
> appropriate binaries you can do this without maintaining anything on the
> clients.  There will be some extra work to support multiple platforms
> but it would just amount to maintaining appropriate NFS exported
> directories for them which you have to do anyway.  A simple approach
> for this would be to use a run-from-cd version of the distribution
> in question on a client to mount/install/update the binaries, or
> use a knoppix-like scheme where you actually export the CD or a
> HD copy of it.
>
> There are still several problems to solve.  One is the difficulty in
> making menus that launch things in the right place if you want to mix
> and match local and remote apps.  X can run things where you want, but
> how do you build menu items that know that some clients should run a
> program as a local app, some on the ltsp server, and maybe others from
> a special app server?   Or is cluster technology coming along fast
> that before you can work this out you would be able to launch a program
> locally and let it migrate itself it that would be better?  This:
> http://kerrighed.org/what_is_kerrighed.html looks promising, but not
> complete yet.
>
> --
>   Les Mikesell
>     les at futuresource.com
>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>