[K12OSN] Plans for K12Linux EL6 and Future Fedora

Sun May 8 19:30:13 UTC 2011

This begs the question:  should we even be looking at Red Hat anymore 
for this?  Would, say, Slackware be a consideration for a K12Linux 
distro?  I would say Debian, but we already have Edubuntu, so that's 
covered.

--TP

Charlie wrote:
> If Terminal Services is not a part of Red Hat's RHEL6 core business 
> strategy, there won't be any consideration given LTSP when making 
> updates or changes to RHEL6.  K12Linux was a major disappointment due 
> to this very reason.   Without a firm commitment from Red Hat, I don't 
> see LTSPv5 on RHEL6 ever being a viable reality.
>
> Red Hat is making a serious third mistake here; the first being no 
> focus on desktop, second no focus on Terminal Services, as VDI is 
> really only one component of the desktop solution options, and limited 
> at that.  Red Hat is losing a large chunk of revenue to competitors 
> due to their lack of support for a small business server solution and 
> Terminal Services, here again M$ has the lions share because they have 
> a more comprehensive product set that addresses business needs, note 
> that I didn't say better, just that they have a solution.  Statistics 
> clearly show that small and medium businesses make up greater than 90% 
> or all businesses. Source: http://www.census.gov/econ/smallbus.html
>
> Currently there are over 80 million Terminal Services clients 
> deployed, while there are only ~2 million VDI deployments (source: 
> http://www.brianmadden.com/, which is an excellent resource for 
> information about remote desktop support and where it's going).  The 
> number of desktops supported on VDI vs Terminal Services is much lower 
> because VDI deployments require far more resources per desktop than 
> Terminal Services, as you noted in your comments below.  
>
> Red Hat has lost significant business to M$ and now will start to do 
> so with Ubuntu, as they do have a plan for Terminal Services and it 
> works now, out of the box, and they have 100% backing by the vendor. 
> If you think not, then do a search on youtube.com or google for 
> k12linux and then do it for Ubuntu LTSP or Edubuntu.  You will see 
> clearly Red Hat is already slipping in the Terminal Services arena.  
> Remember M$'s early days when they understood whoever owns the 
> desktop, owns the server as well?  Well, even Ubuntu figured at one out.
>
> In MHO, I would think it would be more wise for Red Hat to seriously 
> invest in Terminal  Services as much as or more than they have in 
> VDI.  They could overcome a large part of the limitations of 
> multimedia through optimizations made to the remote desktop protocols 
> like SPICE, and how buffering and bandwidth are managed and utilized 
> between the server and the thin client.
>
> -----Original Message-----
> *From*: Warren Togami Jr. <warren at togami.com 
> <mailto:%22Warren%20Togami%20Jr.%22%20%3cwarren at togami.com%3e>>
> *Reply-to*: "Support list for open source software in schools." 
> <k12osn at redhat.com>
> *To*: K12LTSP <k12osn at redhat.com 
> <mailto:K12LTSP%20%3ck12osn at redhat.com%3e>>
> *Subject*: [K12OSN] Plans for K12Linux EL6 and Future Fedora
> *Date*: Sun, 08 May 2011 02:50:37 -1000
>
> Hi folks,
>
> 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 
> support.
>
> 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
> ===================================================
> http://en.wikipedia.org/wiki/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 
> developers.
>
> Warren Togami
> warren at togami.com <mailto:warren at togami.com>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com <mailto:K12OSN at redhat.com>
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>