[K12OSN] Plans for K12Linux EL6 and Future Fedora

[Les Mikesell]

On 5/8/11 6:29 PM, Warren Togami Jr. wrote:
> 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.

There is more to remote X than LTSP/thin clients.  Personally I like freenx and 
almost never sit directly at a Linux console even though most of my work is on a 
Linux desktop.  And I've always thought 'boot-into-nx' would be a reasonable 
thin client approach for wireless access using a CD or other local boot media.

>> 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.

In the beginning, clients were typically old PCs that wouldn't have been good at 
running much anyway.  But now even discarded pcs or cheap new ones would be 
decent fat clients.  There also was the issue of not having good hardware auto 
detection but with the example of Knoppix there are now many boot-and-run 
distributions, many of which have tools for custom rebuilds which would make it 
easy to have them come up with network authentication and home directory access. 
  Now that part is available it would just be a matter of being able to PXE boot 
into custom images built with those same tools.

> 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.

I had the impression that the only reason for taking development into fedora 
which isn't particularly usable was that the packages would be built in a way 
that would minimize future maintenance and would be included in RHEL.  If that 
is now all out the window, where would you suggest starting over?

>
> 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.

Maybe - but at this point counting on SPICE seems pretty theoretical, especially 
if the RHEL package isn't redistributable.  The other issues really need to be 
solved anyway since a typical network will have an assortment of standalone 
boxes as well as the LTSP server and its clients - and the ability to boot a 
standard, centrally managed image would cover most of the maintenance issues.

> 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.

No, I haven't tried it.  What would I have to run to test it?

-- 
   Les Mikesell
    lesmikesell at gmail.com