[K12OSN] Plans for K12Linux EL6 and Future Fedora
Charlie
charlie at smbis.com
Sun May 8 20:12:01 UTC 2011
Personally, this coming school summer recess I plan to switch over to
Ubuntu LTSPv5 for office and admin, and Edubuntu apps added for the
students running as TCs, with only a couple full desktops running Ubuntu
and Windoz. I also plan to look at Skolelinux / DebianEdu
( http://www.slx.no/en/product ), as they quote being able to do
diskless as well as thin-client for desktops. Now that Ubuntu is
cooperating more with the Debian developers, they both should benefit
greatly. There may be other option like you mention, Slackware, or even
SUSE since they are now going back home to Germany per Attachmate's
recently announced plans. I really like Red Hat and wish they would get
serious about the small business market opportunity and Terminal
Services.
-----Original Message-----
From: Terrell Prude' Jr. <microman at cmosnetworks.com>
Reply-to: "Support list for open source software in schools."
<k12osn at redhat.com>
To: Support list for open source software in schools.
<k12osn at redhat.com>
Subject: Re: [K12OSN] Plans for K12Linux EL6 and Future Fedora
Date: Sun, 08 May 2011 15:30:13 -0400
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>
_______________________________________________
K12OSN mailing list
K12OSN at redhat.com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20110508/9d380d99/attachment.htm>
More information about the K12OSN
mailing list