Hello There was a simular thread at debian-edu concluding with following posting: <http://lists.debian.org/debian-edu/2007/07/msg00140.html>
In short: There are usecases for both technologies but for mixed environments the LowFat client of LTSP is the less invasive approach. For example when terminal server is established and there is a need for more powerful clients (multimedia) or it would be a waste of server power if better client hardware arises. gerhard Robert Arkiletian schrieb: > Hello list, > > I know local app support is in the works BUT > > I'm wondering if anyone else is thinking it would be a good idea to > have an option (or even a distro) which runs EVERYTHING on the client. > Much like DRBL http://drbl.sourceforge.net/. The reason for my > suggestion is that I feel the days of Terminal Servers are numbered. > With the advent of Intel Atom like cpus, it now becomes possible to > retain the energy efficiency of previous generation thin clients AND > have enough cpu muscle to run a full desktop. As time goes on these > cpus are only going to get faster. They are already fast enough and > very affordable. > > http://www.newegg.com/Product/Product.aspx?Item=N82E16856167032 > > The benefits of LTSP are ease of administration, maintenance, > affordability and energy efficiency. With Diskless remote booting > these advantages are retained. But the traditional problems and > difficulties in development of LTSP: remote sound, local devices > (ltspfs), cpu hogs (flash), full screen video (network bottlenecks and > sound sync), security (ssh tunnels, X latency), X caching pixmaps > in local ram (firefox, OOo killing X).... they ALL disappear. > > One new problem does arise. The time to initially launch an app may be > slightly increased. Since the app must be loaded from a remote disk, > the network replaces the SATA cable. However, ram is so cheap, if you > stick in 1GB on a client ($20), the 2.6 Linux kernel utilizes most of > the ram by caching app memory. So if you launch FF, close it, then > launch it again, it is much faster second time around. The slowest and > most demanding event in a DRB lab would be boot time. However, this > can be scheduled in a cron job (with WOL) to occur just before school > opens in the morning. Problem solved. > > Fortunately, these new little boxes are shipping with 1000Mbps nics. > In addition, full gigabit port switches are much more affordable than > when they first came out. So for the future, as network switches get > upgraded, this issue should dissapear. FAST disks on the server and a > fat pipe to the switch would be optimal. SSD drives in the future may > hold promise. > > The setup I describe above has been successfully implemented for an > entire school district. Here > http://www.sd73.bc.ca/district-operations.php/page/linux-in-education/ > > Most people who started using LTSP did so by re-using old computers (I > still use PII's) as make shift thin clients. The cost of upgrading an > entire lab was ONLY 1 server. It made sense. I still happily use > K12LTSP today. > > But look at hardware technology/affordability today. I am in line for > funding at the end of this school year. I am most likely going to buy > a whole lab of Atom based systems much like the one linked above > (hopefully the next gen). I wish I could install a Fedora or Ubuntu > DRB distro. > > I hope LTSP developers and distros see this perspective. If others on > this list agree or disagree please speak up as I want the general > consensus to be known. > > > -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
