On Tue, May 06, 2014 at 08:30:27AM +0200, Rolf-Werner Eilert wrote: > > I've also dabbled with the Raspberry PI: > > > > http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/ > > > > But I'm not particularly impressed with the results; some people have been > > using Raspberry PI thin/fat clients in production.
> I know the Raspberry PI a bit and have seen how smoothly it can run > under a dedicated kernel. So I'd guess LTSP's main drawback here is that > it uses the standard kernel of its host OS and if one could pack a > specialized kernel like with LTSP 4, there would be less problems. Well, I've only used the RPI with a kernel built specifically for Raspbian, and worked to get it packaged more like a standard Debian kernel package at one point, largely so that LTSP could be used with it. Well, also because I have an aversion to poorly packaged kernels... Basically, a kernel for the RPI will always be tailored to the hardware. LTSP4 was a bit before my time, but it primarily targeted x86, which could build a single kernel that would work on just about any x86 hardware... but this just isn't feasible with the current state of ARM support in the Linux kernel... it's improving, slightly. > This leads me to my problem with LTSP 5 with too old clients and with my > own client in my office (also something special like ARM, don't remember > exactly). All run perfectly well under LTSP 4 (i. e. with a reduced, > special kernel), but no chance with the standard kernel of the SuSE-Kiwi > LTSP distro. (But this is another topic...) > > Or am I completely wrong here? OSes has grown considerably since the last LTSP4 release (2005?). If LTSP had continued to develop LTSP4, even with some hand-tailoring, it would have also probably bloated a bit over time. With modular kernels, the core kernel shouldn't be that big, but there's some significant variation from distro to distro. It's perhaps even moreso all the other binaries have grown in capability and in resource useage, not just the kernel... X.org is one, but applications like firefox and libreoffice/openoffice also take huge amounts of resources... and a lot of other little binaries running behind the scenes gradually eat RAM and CPU cycles... Some hardware has lost support in newer versions of the kernel or X.org, too. There may not be a technical reason for why it works poorly on a modern linux kernel, except there was nobody to care for it and ensure it continued to work. Major changes to the way things are done that pave way for greater improvements (i.e. kernel mode setting), may require considerable effort to bring a driver up to speed, and developers generally have more time, interest and hardware access to hardware that's reasonably current. Looks like the pcduino a10 variant has rudimentary support in the mainline kernel, for what it's worth. :) live well, vagrant
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce
_____________________________________________________________________
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
