[EMAIL PROTECTED] a écrit :
> On Wednesday 16 May 2007 03:13, [EMAIL PROTECTED] 
> wrote:
>   
>>> Is it possible to have an ubuntu TS client running on Fedora LTSP server?
>>> Is it possible for the TS client to run a different display manager than
>>> the server.
>>> For example,  I like my TS clients to use Xfce eventhough the server is
>>> using Gnome.
>>>       
>> I believe the only way to run a different OS on the client side is with
>> LTSP v5.  I don't think version 4.2 is capable of such without a major
>> overhaul, which is part of why the new v5 way is being developed.  I am
>> sure someone with more expertise could give better detail.  But I know the
>> best way is with v5.
>>
>> As far as the window manager, no problem.  You should be able to yum
>> install xfce or apt-get install xfce and it will be available to the
>> client.  You can choose the "session" at login.  I can't remember how to
>> make a certain session the default for all users but that should be easy to
>> google.
>>     
>
> The thin client is a keyboard/display on the server. The End.
> (sorry to all who are tired of hearing this. How do we define the role of a 
> TC 
> so it's clear and obvious to all who come looking?)
>
> Prior to 5, ltsp was a 'ltsp-distribution' (the reason for creating 5 was the 
> effort in maintaining the ltsp-distro) so it really made no difference at all 
> even in the extreem like ltsp(386) hosted on a sun system.
>
> With ltsp5 you build the client from the host files, but you do not *have* to.
> There are big issues if you change host/client architectures but no reason 
> for 
> it to not work. (you can't chroot and update the client filesystem from the 
> host server)
>
> In the extreem you could host your thin clients off serverA (boot from 
> serverA) and run off serverB. All the window manager stuff would be a 
> function of serverB and TCs would not care about serverA
>
> So it is not possible to have a client *do anything* that the server can't 
> do, 
> but for example your server could run kde, gnome, icewm and xoffice. You get 
> to choose, on a TC just the same as you would on the server console.
>
> Of course this is a simplistic view, but it provides answers to the 
> simplistic 
> confusions that reign eg localapps, localmedia muddy the picture
> James
>   
Sorry, James, but the picture is not clearer after that. You seem to
make a difference between ltsp4 and ltsp5 where there is no such.
The client boots its kernel from server through tftp or pxe, mounts
its filesystem trough nfs (at least on ltsp4) and start the X11 system.
>From there on, what you have is a bare system with no window
manager. You can do some funny things there like running qemu
with windows 95 full screen, or connect, like you do at login on
your server to a specific environment like kde, gnome or xfce.
This is like a normal local login. It makes no difference if you build
the client filesystem with debian or redhat or whatever distro, what
is displayed is only what the server has. It cannot run debian and
redhat at the same time so forget it. The base client filesystem can
hold different files that are run locally. For instance, on our system,
the clients have special drivers/programs that redirect some ports
over tcp to allow for the server to grab them. In fact, the client
image has no problem doing chroot update/install as long as the
architecture is the same, but it is not done normally. It is much
easier for the distro builder to install their own base system.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to