[K12OSN] Plans for K12Linux EL6 and Future Fedora

[Warren Togami Jr.]

On 5/8/2011 3:42 PM, Les Mikesell wrote:
>>> 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.

I was only responding to your comment "seemed so out of touch with the 
way unix/linux is actually used".  I meant that WE are the ones out of 
touch, not them.

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

I did suggest in another reply that Debian LTSP is your best option, as 
Debian's goals are very different from RH it is actually a supportable 
solution in the long-term.  I also applaud Debian's commitment to 
liberty that is similar to Fedora.

Fedora and RHEL's priorities were very quickly moving away from legacy 
designs that would support LTSP with little effort.  It was a constant 
struggle to make LTSP work when the efforts of hundreds of other 
engineers had conflicting priorities.  Debian has entirely different 
goals, remaining firmly rooted in the past, which is why the long 
obsolete LTSP is so easy to support there.

EL6 has enough of the legacy that it could be an awesome platform to 
support LTSP for its seven year lifespan.  It would be great because RH 
updates the critical desktop apps like Firefox and LibreOffice for 
security and bug fixes through all those years.  The only problem here 
is the 32bit userspace binaries and kernel no longer supports anything 
less than i686.  (It may even require SSE2, not sure, so Pentium 3 and 
Athlon Thoroughbred may be too old as clients.)  So it would require 
rebuilding all the packages for i586 and a new kernel in order to 
support LTSP.  That may even be worth doing.  I don't know.  I will 
assess the feasibility.

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

Could you point out links to that centos discussion?  Fedora ships the 
core of SPICE client and server, so I don't see how CentOS would be 
unable to ship it.  Perhaps they were confused with the non-open 
management suite.

It is DIFFICULT to use without the management suite.  It's like using 
qemu with command line options.  Functional but difficult.  A K12Linux 
based on kvm would need a management wrapper written from scratch to 
make it simple.

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

Too difficult to explain quickly.

Warren