[K12OSN] Plans for K12Linux EL6 and Future Fedora

[Warren Togami Jr.]

On 5/8/2011 6:40 AM, Les Mikesell wrote:
>> * 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.
>
> That's ummm, extremely unfortunate. I gave up even looking at Fedora
> long ago because they seemed so out of touch with the way unix/linux is
> actually used, apparently wanting to turn it into a single-user toy. On

This is really a point of view issue.  In reality, the GNOME 3 direction 
pioneered by Fedora is what the vast majority of users want in the 
future.  LTSP is and has always been in the extreme minority.

> the other hand, it is fairly likely that future client hardware would be
> able to run the desktop locally, given a way to boot a fairly fat client.

This is a good point.  This would effectively negate the issues of a 
remote desktop protocol and fully use the power of modern client hardware.

However, this approach has always been a good idea.  Yet oddly enough, 
nobody did it.  I suspect it is because it requires significantly more 
effort to it was to make LTSP.  With almost nothing running on the 
client, LTSP was very easy to deploy and manage.

No matter how good an idea it might be, in reality it wont happen if 
people don't develop it.  For years Eric Harrison was the only developer 
on RH LTSP, then it was only me for a few following years.  For years 
I've asked this community for volunteer help but received almost none.

In other words, talk is cheap.

>
>> 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.
>
> Is spice licensed for redistribution? I thought I just saw something
> mentioned on the Centos list that they couldn't include it in 6.x.

This is a good question.  My knowledge is a year old, but back then the 
core components of the SPICE client (sans remote USB) and kvm 
server-side were open source.  The management solution is not Open 
Source, but a theoretical Fedora-based VDI solution would need to 
implement its own simple service to manage the virtual machines via the 
libvirt API.

>
>> 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.
>
> Seems like the wrong way to go compared to booting something that can
> run video locally. That is, you are adding several layers that are going
> to require cpu cycles and probably use a less efficient network protocol
> than the original video source format. There would be some tradeoffs
> between beefing up the server and the clients, but needing to do both
> sounds wrong.

Again, I agree that netbooting semi-fat clients would perform better 
than any remote desktop protocol.  But there are significant trade-offs. 
  It is significantly easier to implement this, and manageability and 
security are significantly better with all desktop VM's running in a 
central location.

>
>> 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.
>
> How would it compare to, say, running vlc directly on the client where
> for classroom use you could multicast the stream to scale out?
>

Of course vlc locally is better.  But have you actually tried 
full-screen video on multi-monitor setups over the SPICE protocol?  It 
is surprisingly not bad.  Fairly low CPU usage on the server, moderate 
bandwidth to the client.  The main bottleneck is the CPU of the client 
hardware.

Video is not an issue with VDI.  The lack of Composite is an issue that 
may make it infeasible as Fedora and Ubuntu both go to composite 
desktops by default.

Warren Togami
warren at togami.com