<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> See below... -----Original Message----- <PRE> On 5/8/2011 8:49 AM, 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. This is a bit of an overstatement. I personally made sure that the technology in RHEL6 would be capable of supporting legacy LTSP no worse than previous versions of Fedora. RHEL6 contains GNOME 2 which works fine with LTSP and remote desktops. The ONLY major issue is the 32bit i686 minimum arch which excludes the vast majority of past LTSP client hardware. NOTE: I no longer work for Red Hat. </PRE> I would think updating minimal hardware technology requirements as simply being a part of technology evolution. This is not something that should get in the way of developing a product strategy. Given that i686 is in reality a very mature technology and most businesses have phased it out, so there should be plenty of i686 used/donated product out there. Why is it that Debian/Ubuntu have a LTSPv5 solution and Red Hat does not? I'm not talking about well if this or if that then RHELv6 would support a Fedora version, that is maybe one or two revisions behind and possibly not getting updates any longer, as being the solution. Again, Red Hat needs to get serious with a clear desktop solution strategy. VDI is only one, Terminal Services is another, Diskless Fat Client, Full stand-alone desktop is another... <PRE> > > 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. I don't dispute that VDI has significant penetration, but the harsh truth is the LTSP approach to Terminal Servers has NEVER made any money for anybody. Ubuntu has tried and failed to sell support contracts for LTSP as a business model. It is a fantasy to believe that the old Terminal Server model makes business sense for anyone. </PRE> Actually the point was that VDI has only about 2% market penetration after two plus years as compared to Terminal Services. I also have to disagree with you here on Terminal Services model not making any business sense, please take some time and check out the <A HREF="http://www.brianmadden.org/">http://www.brianmadden.org/</A> blog which totally refutes this. There are companies built around that model; Citrix, NX, 2X... M$ reworked their Terminal Services strategy a while back with Server 2008 to address this growing market. I know first hand companies that have recently deployed Terminal Services using thin clients to replace desktop PCs, primarily to reduce help support and PC upgrade costs. Reality is that as we migrate back to the central server in the data center (think mainframe era, only with a new twist) and cloud computing, where you have SaaS, Terminal Services makes more sense. Ideally a multiple approach to desktop solutions makes better sense, be it Thin-Client using LTSP or VDI, or Fat or Full Client desktop solutions, they all need to be on the table as options to meet customer requirements. Thanks for your feedback here as well as everything you do. Charlie Warren <PRE> _______________________________________________ K12OSN mailing list <A HREF="mailto:K12OSN@redhat.com">K12OSN@redhat.com</A> <A HREF="https://www.redhat.com/mailman/listinfo/k12osn">https://www.redhat.com/mailman/listinfo/k12osn</A> For more info see <<A HREF="http://www.k12os.org">http://www.k12os.org</A>> </PRE> </BODY> </HTML>