[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Trouble with PXE Boot; Fedora 17



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 30, 2013, at 12:46 AM, Adrin Gharakhani wrote:

> 
> 
> On Jan 29, 2013, at 10:42 PM, Burke Almquist wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> So are you have a big workstation with lots of horsepower you want to run this stuff on, you just would like to access it from a remote computer?
> 
> Yes, precisely
> 
>> Then NX might be the best option here.
> 
> Except that I remember from somewhere that LTSP is supposed to be faster than NX on a LAN 
This is probably true. X is actually very responsive over a good LAN connection. 100mbit on the clients and 1gbit on the server should provide plenty of bandwidth. The advantage of NX is on connections that have greater latency and less bandwith (over the internet for example) as opposed to a 100mbit or gigabit speed LAN.

LTSP 4.0 used XDMCP to establish a remote X Session. No security (I mean it's on a switched network, but ARP spoofing would make traffic sniffing possible) and no compression.

LTSP 5.0 has moved to tunneling over SSH. This adds some security, and the use of built in SSH compression, but requires just slightly more horsepower from the client. You CAN specify the use of the SSH tunnel only during the login process in the lts.conf file (this is the default on some distros). This lowers the burden on the client hardware while still protecting the user's password over the wires. All the X traffic itself is unencrypted if you choose this though, so it's not the best for security. Best on a small and closed network. 

NX also uses SSH for security but has it's own compression that is much more effective than the built in SSH compression. The work of doing the compression is only worth while if the connection is slow enough or has high enough latency. Otherwise you are just burning CPU cycles for no performance gain, and actually the overhead of the higher compression would introduce more latency that it fixes over a faster connection.


> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>> 
>> iEYEARECAAYFAlEIwOwACgkQxWV7OPa/g5Gy1ACfWUjWhI4VmqfL4hAMe4jfLhdY
>> cXgAn3vq5OXKjRVBfALYQGUNNJ9VD5hg
>> =lULx
>> -----END PGP SIGNATURE-----
>> 
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN redhat com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see <http://www.k12os.org>
>> 
> 
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlEKFLMACgkQxWV7OPa/g5Hp/ACeNfTjPQbDS6oAC+aG6va6xAaY
SdgAnA3O0Jd+soA68grB/VHzxSIy/BGb
=RFEB
-----END PGP SIGNATURE-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]