Warren Togami Jr.
2011-05-08 12:50:37 UTC
It has been a LONG while since I've been able to look at k12linux.org,
but I haven't forgotten about this project. 2007 through 2009 Red Hat
generously supported my time to work on this project. In 2010 I've
since left Red Hat in order to help my parents with the family business
and prepare for grad school.
K12Linux LTSP EL6
I soon plan on working on a version of LTSP based on EL6.
Since CentOS *still* hasn't released their EL6 clone, I am thinking to
base it on SL6. I suspect it wont be much work to adapt Gavin's work to
make a EL6 based K12Linux since not much changed between F13 and EL6 and
they both use Upstart.
BIGGEST PROBLEM: 32bit EL6 supports a minimum of i686 and they have
excluded certain kernel modules required by LTSP like nbd.ko. For this
reason, we may need clients of EL6 to boot images based on Fedora
12/13?/14? that still have userspace capable of running on i586. I
would need to see what are the supported archs and kernels in those
versions of Fedora.
At the moment I suspect this might be doable with about a week of my
effort. I've entirely given up on expecting development help from you
the community after I've asked in vain from you folks these past years.
That's OK. I will try. But I am only able to pick the low hanging
fruit. If I cannot quickly make it work, then this will be the end.
(If someone is willing to financially sponsor my time, I may be willing
to put more effort into this. Contact me privately if interested.)
The LTSP based on EL6 would likely be the LAST version of LTSP for a
RH-derived distribution. Given the LONG lifespan of EL6 this should
give the considerable numbers of existing LTSP deployments many years of
life. However, since the only maintainable way we can build the client
images for EL6 is from a particular old Fedora version, this effectively
means that K12Linux LTSP EL6 will be frozen forever in client hardware
Fedora 15+? LTSP IS OBSOLETE
Theoretically LTSP upstream could be adapted to work with Fedora 15+,
but for a number of reasons it has become impractical to expect
continued support for LTSP in Fedora.
* LTSP relies on the ancient and almost now untested functionality of
remote X. Fedora 8 through 12 I was effectively the only Red Hat
engineer working on remote X desktop and netboot issues. The entire
Fedora distro will continue to further drift away from working remote X
desktops as it simply was never a priority.
* Fedora 15+'s GNOME 3 will be totally incompatible with the vast
majority of LTSP client hardware incapable of compositing, while the
non-composited fallback is likely to be poorly tested and poorly
supported, especially in the remote X case which nobody but LTSP would use.
* As Fedora progresses, its 32bit kernel and userspace will drop support
for the majority of LTSP client hardware, if it hasn't already happened.
* A possible way to keep Fedora LTSP somewhat working for a few more
years might be to switch the default desktop to something else like KDE
or XFCE that relies on just plain non-composited X. But that is still a
non-trivial amount of effort to make it a smooth user experience since
remote X is poorly tested there as well.
For these reasons, and the fact that I am no longer sponsored to work on
this, it seems unlikely that LTSP will ever again be officially
supported by Fedora.
Next Generation of K12Linux: Desktop Virtualization
I have been thinking about a theoretical next generation technology
replacement for LTSP. Fedora contains the remote desktop protocol SPICE
and kvm, the Open Source core components of a VDI solution.
A theoretical K12Linux based on SPICE would have each user's desktop
running within their own virtual machine on a pool of centralized
servers. Maybe each user's desktop VM would be hibernated to disk when
their client disconnects in order to conserve central server resources.
The desktop GUI and sound would be forwarded over the network and
viewable with the SPICE client running on thin clients. This would
theoretically allow K12Linux deployments to connect to any mix of both
Windows or Linux virtualized desktop machines, although K12Linux would
only document the Linux case.
SPICE requires much beefier client hardware. It appears that first
generation Intel Atom with i950 video is only borderline powerful enough
to handle it.
I suspect that SPICE will never support compositing. So a VDI-based
Fedora 15+ would be using the non-compositing fallback (which I've only
heard about but never tried). At least it wont rely on the almost
untested remote X functionality.
Youtube sucks much less over the SPICE protocol than with remote X of
LTSP. Modern expectations of stuff like video are another nail in the
coffin for the old LTSP model.
This is all very theoretical. The problems involved to make this a
smooth user experience may make this plan infeasible for volunteer