Plans for K12Linux EL6 and Future Fedora

[Warren Togami Jr.]

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
***@togami.com

[Les Mikesell]

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.

I've always thought it would be useful to have a generic PXE boot mechanism into
a livecd image on the server. That way you could use any distribution's live cd
or dvd image or use the tools they provide to build a custom version and it
would work the same whether booted locally or over the network - and importantly
for this use would not take per-client maintenance. I think DRBL can boot at
least a clonezilla-live image but don't know if other images would work.

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

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.

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.

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?

[Warren Togami Jr.]

* 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
***@togami.com

[Les Mikesell]

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

[Warren Togami Jr.]

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

[Les Mikesell]

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.

And I meant that they are turning it into something that doesn't suit the
reasons I've used unix/linux systems. If that means I'm out of touch, fine, but
if I want a single user box that needs one special console attached in a certain
place and forces you to sit there to do anything useful, I probably wouldn't be
using unix/linux.

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.

I guess I overstated the issue - it was just the spice-usb-redirector package:
http://www.linux-archive.org/centos-development/523021-missing-package-spice-usb-redirector-ceea-2010-0460-a.html

[Charlie]

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. <***@togami.com>
Reply-to: "Support list for open source software in schools."
<***@redhat.com>
To: K12LTSP <***@redhat.com>
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
***@togami.com

[Terrell Prude' Jr.]

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

Post by Charlie
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
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-----
*Reply-to*: "Support list for open source software in schools."
*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
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>
------------------------------------------------------------------------
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Charlie]

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. <***@cmosnetworks.com>
Reply-to: "Support list for open source software in schools."
<***@redhat.com>
To: Support list for open source software in schools.
<***@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

Post by Charlie
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
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-----
*Reply-to*: "Support list for open source software in schools."
*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
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>
------------------------------------------------------------------------
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Warren Togami Jr.]

Post by Charlie
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.

I know the Debian LTSP developers personally. They are good people, and
Debian is a respectable Linux distribution with a similar commitment to
liberty as Fedora. I can highly recommend Debian LTSP, because upstream
ltsp.org features are developed for Debian first.

Warren

[Warren Togami Jr.]

Post by Charlie
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.

Post by Charlie
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.

Warren

[Charlie]

See below...

-----Original Message-----

Post by Charlie
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.


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

Post by Charlie
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.


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
http://www.brianmadden.org/ 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

[Charlie]

Correction that link to Brian Madden Blog is
http://www.brianmadden.com/, and M$ Terminal Services I am referring to
is their marketing name Remote Desktop Services (RDS), here is the link:
http://www.microsoft.com/windowsserver2008/en/us/rds-product-home.aspx

-----Original Message-----
From: Charlie <***@smbis.com>
Reply-to: ***@smbis.com, "Support list for open source software in
schools." <***@redhat.com>
To: Support list for open source software in schools.
<***@redhat.com>
Subject: Re: [K12OSN] Plans for K12Linux EL6 and Future Fedora
Date: Sun, 08 May 2011 22:16:06 -0400

See below...

-----Original Message-----

Post by Charlie
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.


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

Post by Charlie
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.


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
http://www.brianmadden.org/ 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


_______________________________________________
K12OSN mailing list
***@redhat.com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Jeff Siddall]

Post by Warren Togami Jr.
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.

Thanks Warren, I am eagerly awaiting this as a long term migration
platform for my current K12Linux systems.

Post by Warren Togami Jr.
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.

Personally I don't care about this really. Even the lowly Atom is i686
and as I have argued on this list before the business case for re-using
old fat desktop hardware doesn't exist if you consider the cost of
power. I am far more concerned with the easy manageability LTSP provides.

Post by Warren Togami Jr.
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.

I am happy with the prospect of 7 more years of LTSP. I certainly hope
that 7 years from now we have a better solution!

Post by Warren Togami Jr.
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.

I already added a GSoC request for someone to implement just that. I
think this would be a great LTSP replacement.

Post by Warren Togami Jr.
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.

I agree with all this although I can't imagine SPICE going far without
compositing. We already have that in legacy remote X!

Post by Warren Togami Jr.
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.

Honestly this is my biggest problem with LTSP right now. Video in LTSP
just plain sucks.

I for one think LTSP5 on CentOS 6 (or equiv.) would be a great solution
for the foreseeable future and am really hoping you find the
time/encouragement to do it.

Jeff

[Warren Togami Jr.]

Post by Jeff Siddall

Post by Warren Togami Jr.
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.

Thanks Warren, I am eagerly awaiting this as a long term migration
platform for my current K12Linux systems.

I am reconsidering the worth of working on this project. This has not
been much of a positive response. In fact most of the response has been
only bitching from people who want everything but are willing to
contribute nothing. Not having worked on this for years I had forgot
how thankless this work is.

I may consider releasing it only if enough people are willing to donate
to make this thankless grief worthwhile.

Post by Jeff Siddall

Post by Warren Togami Jr.
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.

Personally I don't care about this really. Even the lowly Atom is i686
and as I have argued on this list before the business case for re-using
old fat desktop hardware doesn't exist if you consider the cost of
power. I am far more concerned with the easy manageability LTSP provides.

I have since discovered the actual minimum requirements for 32bit EL6.
i686 minimum, and the kernel requires PAE hardware. Some discussion
seems to suggest it is reasonably easy to rebuild the EL6 kernel without
PAE.

i686 is considered to be:

* "Pentium Pro or later"
* "AMD K6 (but not all) or later"
* "Via C7" or later
* Geode LX, but not Geode GX

So minimal effort would support only more recent LTSP clients, which I
guess would be the minority of deployed hardware.

Warren

[Warren Togami Jr.]

Post by Warren Togami Jr.
* "Pentium Pro or later"
* "AMD K6 (but not all) or later"
* "Via C7" or later
* Geode LX, but not Geode GX

OK, Geode LX may not be supported either, likely due to the userspace
libraries being built with certain compiler flags.

Warren

[Jeff Siddall]

Post by Warren Togami Jr.

Post by Warren Togami Jr.
* "Pentium Pro or later"
* "AMD K6 (but not all) or later"
* "Via C7" or later
* Geode LX, but not Geode GX

OK, Geode LX may not be supported either, likely due to the userspace
libraries being built with certain compiler flags.
Warren

I guess my "lowly" Atom clients are screamers compared to some people's
old junk but can't those people with really ancient hardware just stick
with K12LTSP (LTSP4)? Anyone running K12Linux has already had to deal
with the lack of i586 support for a number of years now.

Even if new clients were required to keep things running for another
seven years (is that really so bad?), it's literally a matter of $86 per
machine to get an 1.66 GHz Atom D410 and 1 GB DDR2 RAM from newegg.com.
Some searching could probably find some even cheaper options.

Jeff

[Terrell Prude' Jr.]

Post by Jeff Siddall

Post by Warren Togami Jr.

Post by Warren Togami Jr.
* "Pentium Pro or later"
* "AMD K6 (but not all) or later"
* "Via C7" or later
* Geode LX, but not Geode GX

OK, Geode LX may not be supported either, likely due to the userspace
libraries being built with certain compiler flags.
Warren

I guess my "lowly" Atom clients are screamers compared to some people's
old junk but can't those people with really ancient hardware just stick
with K12LTSP (LTSP4)? Anyone running K12Linux has already had to deal
with the lack of i586 support for a number of years now.
Even if new clients were required to keep things running for another
seven years (is that really so bad?), it's literally a matter of $86 per
machine to get an 1.66 GHz Atom D410 and 1 GB DDR2 RAM from newegg.com.
Some searching could probably find some even cheaper options.
Jeff

Frankly, K12LTSP 5EL is still doing the job for me. I have no real
reason to upgrade, given my needs, and I doubt that most offices do, either.

As Les Mikesell said, Eric Harrison is a tough act to follow. Warren,
nobody in their right mind would blame you for not wanting to do this
anymore. If you do, though, then you're a saint.

--TP

[Rob Owens]

Post by Jeff Siddall
Even if new clients were required to keep things running for another
seven years (is that really so bad?), it's literally a matter of $86 per
machine to get an 1.66 GHz Atom D410 and 1 GB DDR2 RAM from newegg.com.
Some searching could probably find some even cheaper options.

Jeff, could you give me some part numbers or links at newegg? Or is
this not including a case, power supply, etc?

[Jim Kinney]

http://www.norhtec.com/products/index.html

The MicroClient JrMx is outstanding at $150
They also have the Gecko laptop at $199 that just screams lightweight Linux
school tool.

When I was closing out after the APS project, the MicroClient Jr was what we
were evaluating as a clear replacement for the HP stuff APS bought.

Post by Rob Owens

Post by Jeff Siddall
Even if new clients were required to keep things running for another
seven years (is that really so bad?), it's literally a matter of $86 per
machine to get an 1.66 GHz Atom D410 and 1 GB DDR2 RAM from newegg.com.
Some searching could probably find some even cheaper options.

Jeff, could you give me some part numbers or links at newegg? Or is
this not including a case, power supply, etc?
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Jeff Siddall]

Post by Rob Owens

Post by Jeff Siddall
Even if new clients were required to keep things running for another
seven years (is that really so bad?), it's literally a matter of $86 per
machine to get an 1.66 GHz Atom D410 and 1 GB DDR2 RAM from newegg.com.
Some searching could probably find some even cheaper options.

Jeff, could you give me some part numbers or links at newegg? Or is
this not including a case, power supply, etc?

$86 is just the MB/CPU/RAM:

http://www.newegg.com/Product/Product.aspx?Item=N82E16813121398&cm_re=D410PT-_-13-121-398-_-Product

http://www.newegg.com/Product/Product.aspx?Item=N82E16820134216

The existing case/PS/monitor/keyboard/mouse would need to be reused.

If a new small case/PS/MB/CPU/RAM combo is required then this might work
(just add memory from newegg above):

http://www.logicsupply.com/products/bp_3500_nm1

A complete thin client for $94 is a really amazing price, but I don't
know how well a ZOTAC NM10 works as a Linux client.

Jeff

[Jim Kinney]

Post by Jeff Siddall

Post by Warren Togami Jr.
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.

Thanks Warren, I am eagerly awaiting this as a long term migration
platform for my current K12Linux systems.

I am reconsidering the worth of working on this project. This has not been
much of a positive response. In fact most of the response has been only
bitching from people who want everything but are willing to contribute
nothing. Not having worked on this for years I had forgot how thankless
this work is.
I may consider releasing it only if enough people are willing to donate to
make this thankless grief worthwhile.

It _is_ a pile of work. Unfortunately, keeping support in place for the
rapidly aging piles of old hardware used by schools is going to be a growing
problem. It's not going to be solvable by sticking to the Fedora distro tree
for the clients. It's going to involve either building a mechanism that will
provide the old clients with same code but compiled for their old hardware
from either an alternate distro (not too hard to do) or require an "in the
field" build process that can be run to provide the capabilities. The later,
especially if building a full distro, is just not feasible.

I was looking at the need a few years back when I was pounding on K12LTSP
for a process to determine the capabilities of a client by using a _very_
compatible kernel for an initial tftp load with an initrd that has every
known and buildable modules. So the system runs a hardware test mode to see
what is available, sends that data back to the master node and either a
custom kernel/module pack is built or is uses an existing one based on a
database lookup of hardware known to the system. Once found it resets the
tftp kernel to be a real one.

hehe, I even named this process "shoe-horn" (from the cobbler/koan line of
thinking) as it helps the system fit into a tight boot :-)

I'm moving back to the LTSP world more so I'll be able to pitch in some help
and build systems (as soon as I get mock and koji playing nicely at home).

Post by Jeff Siddall
BIGGEST PROBLEM: 32bit EL6 supports a minimum of i686 and they have

Post by Warren Togami Jr.
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.

Personally I don't care about this really. Even the lowly Atom is i686
and as I have argued on this list before the business case for re-using
old fat desktop hardware doesn't exist if you consider the cost of
power. I am far more concerned with the easy manageability LTSP provides.

I have since discovered the actual minimum requirements for 32bit EL6. i686
minimum, and the kernel requires PAE hardware. Some discussion seems to
suggest it is reasonably easy to rebuild the EL6 kernel without PAE.

Monthly power bills are always bad with old crap running. But to add in
getting new hardware (spend now + deploy in a few months) PLUS the bad power
bills is just not an option for most schools right now. What they that does
work is better than what they want that they can't afford to buy without
laying off another round of teachers.

So we have to find a way to keep that old crap running for them a while
longer. So maybe a full release build that will run on i386, no upgraded
flags, with a minimal X environment is feasible. Dunno. I've never compiled
a full distro before. Maybe it' time I did.

* "Pentium Pro or later"
* "AMD K6 (but not all) or later"
* "Via C7" or later
* Geode LX, but not Geode GX
So minimal effort would support only more recent LTSP clients, which I
guess would be the minority of deployed hardware.
Warren
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Warren Togami Jr.]

Post by Jim Kinney
Monthly power bills are always bad with old crap running. But to add in
getting new hardware (spend now + deploy in a few months) PLUS the bad
power bills is just not an option for most schools right now. What they
that does work is better than what they want that they can't afford to
buy without laying off another round of teachers.
So we have to find a way to keep that old crap running for them a while
longer. So maybe a full release build that will run on i386, no upgraded
flags, with a minimal X environment is feasible. Dunno. I've never
compiled a full distro before. Maybe it' time I did.

Reconfiguring and rebuilding all the necessary packages might make it
1000% extra work, especially if you try to do so for package updates
later, if you want to take advantage of bug fixes and driver
improvements to improve client hardware support. This may be the
infeasible part.

Warren

[Jim Kinney]

Post by Jim Kinney
Monthly power bills are always bad with old crap running. But to add in
getting new hardware (spend now + deploy in a few months) PLUS the bad
power bills is just not an option for most schools right now. What they
that does work is better than what they want that they can't afford to
buy without laying off another round of teachers.
So we have to find a way to keep that old crap running for them a while
longer. So maybe a full release build that will run on i386, no upgraded
flags, with a minimal X environment is feasible. Dunno. I've never
compiled a full distro before. Maybe it' time I did.

Reconfiguring and rebuilding all the necessary packages might make it 1000%
extra work, especially if you try to do so for package updates later, if you
want to take advantage of bug fixes and driver improvements to improve
client hardware support. This may be the infeasible part.

That's why the ONLY way it can work is to have something like a koji system
working on the auto-builds.
The raw assumption is that most things can be built for minimal hardware
with a basic recompile using flags for minimal hardware. So a patch file is
needed but most likely a configuration setting for the mock backend for
koji.

Warren
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Les Mikesell]

Post by Jim Kinney
Monthly power bills are always bad with old crap running. But to add in
getting new hardware (spend now + deploy in a few months) PLUS the bad
power bills is just not an option for most schools right now. What they
that does work is better than what they want that they can't afford to
buy without laying off another round of teachers.
So we have to find a way to keep that old crap running for them a while
longer. So maybe a full release build that will run on i386, no upgraded
flags, with a minimal X environment is feasible. Dunno. I've never
compiled a full distro before. Maybe it' time I did.

The k12ltsp EL5 version should still work for old hardware as long as it is all
old hardware where ltsp4 works. CentOS 5 should have 3 more years of update
support.

Reconfiguring and rebuilding all the necessary packages might make it 1000%
extra work, especially if you try to do so for package updates later, if you
want to take advantage of bug fixes and driver improvements to improve client
hardware support. This may be the infeasible part.

Would it be more feasible to use DRBL as the PXE boot manager and custom-tune
some small linux distro (like Puppy) that it could boot from an iso image?
That would divorce the server/client builds completely and perhaps offer a way
to run different versions on different clients. It wants to put the whole image
in RAM on the client so it might be an exercise in trimming out all unneeded
programs. On the plus side you might be able to build a USB or CD boot, NX
client version of the same image that would be perfect for wifi clients without
much extra effort.

[Warren Togami Jr.]

Post by Les Mikesell
Would it be more feasible to use DRBL as the PXE boot manager and
custom-tune some small linux distro (like Puppy) that it could boot from
an iso image? That would divorce the server/client builds completely and
perhaps offer a way to run different versions on different clients. It
wants to put the whole image in RAM on the client so it might be an
exercise in trimming out all unneeded programs. On the plus side you
might be able to build a USB or CD boot, NX client version of the same
image that would be perfect for wifi clients without much extra effort.

A Debian-based chroot for /opt/ltsp/i386 would likely be the easiest to
deploy as the client OS. It would be minimal additional work.

I suppose I'll make a i686 EL6 /opt/ltsp/i386 the standard, and you can
optionally download a tarball containing the same thing but from Debian
if you need to support old hardware.

Warren

[Les Mikesell]

Post by Warren Togami Jr.

Post by Les Mikesell
Would it be more feasible to use DRBL as the PXE boot manager and
custom-tune some small linux distro (like Puppy) that it could boot from
an iso image? That would divorce the server/client builds completely and
perhaps offer a way to run different versions on different clients. It
wants to put the whole image in RAM on the client so it might be an
exercise in trimming out all unneeded programs. On the plus side you
might be able to build a USB or CD boot, NX client version of the same
image that would be perfect for wifi clients without much extra effort.

A Debian-based chroot for /opt/ltsp/i386 would likely be the easiest to
deploy as the client OS. It would be minimal additional work.
I suppose I'll make a i686 EL6 /opt/ltsp/i386 the standard, and you can
optionally download a tarball containing the same thing but from Debian
if you need to support old hardware.

Could this possibly be done as a script that scarfs the needed items
from a debian or ubuntu livecd or iso file (with or without wrapping it
as an intermediate rpm)? The idea would be to minimize the repeated
work as the alternate distro updates and to offer a choice of debian for
anyone who cares about including non-free firmware or ubuntu for devices
that need it. The differences come up once in a while regarding
clonezilla-live and are likely to affect thin clients too.

Or even better, let multiple client roots exist if it's not too much
trouble to control the default.

[Les Mikesell]

I am reconsidering the worth of working on this project. This has not been much
of a positive response. In fact most of the response has been only bitching from
people who want everything but are willing to contribute nothing. Not having
worked on this for years I had forgot how thankless this work is.

Feel free to ignore anything I say. I don't have a real need for the project
and just hang out here because I liked the "other" usability enhancements Eric
threw into his rebuild (a working rpm-managed java back when Red Hat made that
very difficult, webmin, acrobat reader, etc.) and it is sometime fun to answer
sysadmin type questions from teachers.

But, I don't see how any amount of contribution toward the fedora packaging
effort could have changed the way things ended up. And in retrospect I see why
the original version had to be a respin built to just come up working. Eric is
a tough act to follow.

[Gavin Spurgeon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Warren Togami Jr.

Post by Jeff Siddall

Post by Warren Togami Jr.
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.

Thanks Warren, I am eagerly awaiting this as a long term migration
platform for my current K12Linux systems.

I am reconsidering the worth of working on this project. This has not
been much of a positive response. In fact most of the response has been
only bitching from people who want everything but are willing to
contribute nothing. Not having worked on this for years I had forgot
how thankless this work is.
I may consider releasing it only if enough people are willing to donate
to make this thankless grief worthwhile.

The work that I did to make the packages work on F13 was minimal, All I
did was to take to current upstream code and package it with some very
very small changes to one or 2 txt conf files.

I am sure that I/we/others could do the same with the current upstream
code on F14, F15 or even EL6/CentOS/SL6.

I have a week of down time from my day-2-day job coming very soon, so
would have no issue trying get a very basic current upstream version
built and packaged (.rpm) ready for people to test, I had loads of
people contact me about testing the .rpm's I built for F13 and loads of
feedback for users who did play with the packages on both F13 & F14.

I was in the process of trying to work out how on earth to get my .spec
files uploaded to the Fedora Build system so that KoJi could auto built
them, but never worked it out in the end.

@ Warren, If you could help by pointing me to some instructions on how
you got LTSP in there in the 1st place, I could then move thing forward
a little bit more with the new builds if needs be and try to get the
ball rolling again.

When it comes to your comment about "how thankless this work is" Your
time @ Red Hat should have made you well used to that by now ;-)

I also know that not a lot of people are on this mailing list that use
the LTSP packages on Fedora anyway, I was talking to a lot of people
over on the #ltsp irc channel that had no idea this mailing list even
exists or that K12LTSP for that matter, they just know LTSP and do 'yum
install ltsp' on Fedora.

They have now be educated :-)

- --

Gavin Spurgeon.
AKA Da Geek

- ----------------------------------------------------------------------
"The happiest of people don't necessarily have the best of everything,
they just make the most of everything that comes along their way.."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3L/pQACgkQvp6arS3vDiq4egCgs1evPDNsPzCFcIHLmlb07miw
HZsAn24g8yHZsw8jqqJYWpxIOc9uPMtq
=+uiS
-----END PGP SIGNATURE-----

--
This message was scanned by DaGeek Spam Filter and is believed to be clean.

[Jan Middelkoop]

Dear list,

Gavin attended me to this mailing list in #ltsp. I didn't know of it's
existance before. For the past few days I've been eargerly following
the discussion going on here about the future of LTSP in RHEL and (more
importantly, to me) Fedora.

Eagerly, because I've recently deployed Fedora-powered LTSP terminal
server and clients in our company and I would be very, very sad if it
were discontinued so soon. It's more than that though. I also firmly
believe that a project like LTSP is a wonderful piece of software and
deserves to be a part of Fedora.

For lack of knowledge I cannot join in on the debate about if LTSP and
remote X is technically a good solution and if there couldn't be better
ones. I do however think it seems premature to drop LTSP support in
Fedora. I don't think Fedora currently contains a piece of software
that provides the same ease of use and functionality as LTSP (correct me
if I'm wrong).

I believe LTSP brings unique functionality to Fedora. One thing I
haven't heard an alternative for in the debate going on now, is running
applications locally on the clients, yet integrating them nicely into
the desktop environment. Something LTSP does, with remote X. This
functionality is vital for our company. We use VoIP softphones for our
telephony needs. When I run a softphone on the LTSP server, it simply
doesn't work flawless (I've tried most, if not all). There are too many
problems with the audio. When I run the softphone locally on the
clients (cutting out the middle man), most work flawless. I cannot see
softphones performing well in a virtualized environment.

I am not one to stand in the way of forward thinking and/or new
technological endeavours. I think the idea put forth by Warren could
have merit. I think running every client inside a virtualized
environment will use a lot of extra resources, but this should not be a
problem with the next generation of hardware. However I don't believe
we are there yet. I think LTSP is still a great solution for creating
centralized management and centralized resources for all client
computers in a company.

I would also like to give a short response to Warren's point about the
lack of people who contribute to this project.

I try to spend around ten hours per week supporting open source
development, in one way or another. I have written documentation,
translated packages to Dutch (including LDM at one point), submitted
bugs and bugfixes, and yet... somehow I've never gotten involved with
K12Linux. Why? Because K12Linux seems distanced from Fedora. In fact,
for a long time I've had the impression that K12Linux was a Linux
distribution by itself, having LTSP readily configured for Fedora. As I
have no interest in that, and just want LTSP in regular Fedora, I've
never gotten involved. I think this project could be presented better
and explained better to Fedora LTSP users. This could lead to more
people getting involved.

As another example I would like to point out that Gavin has had working
RPM's of a recent LTSP version for Fedora 13 and Fedora 14 for over half
a year now. They've been tested by many people and the results were
very promising. Yet they still aren't distributed with those Fedora
releases. Why? These seem like the contributions from the community
you have been looking for, and they're left 'out in the rain', so to speak.

These are my $0,02 on the whole situation. I really hope Gavin will
find the time and inspiration to continue building LTSP for Fedora, and
that he will be supported by everyone in doing so. I know I will
support LTSP under Fedora in any way that I can.

Kindest regards,
Jan Middelkoop

Post by Gavin Spurgeon
The work that I did to make the packages work on F13 was minimal, All I
did was to take to current upstream code and package it with some very
very small changes to one or 2 txt conf files.
I am sure that I/we/others could do the same with the current upstream
code on F14, F15 or even EL6/CentOS/SL6.
I have a week of down time from my day-2-day job coming very soon, so
would have no issue trying get a very basic current upstream version
built and packaged (.rpm) ready for people to test, I had loads of
people contact me about testing the .rpm's I built for F13 and loads of
feedback for users who did play with the packages on both F13& F14.
I was in the process of trying to work out how on earth to get my .spec
files uploaded to the Fedora Build system so that KoJi could auto built
them, but never worked it out in the end.
@ Warren, If you could help by pointing me to some instructions on how
you got LTSP in there in the 1st place, I could then move thing forward
a little bit more with the new builds if needs be and try to get the
ball rolling again.
When it comes to your comment about "how thankless this work is" Your
I also know that not a lot of people are on this mailing list that use
the LTSP packages on Fedora anyway, I was talking to a lot of people
over on the #ltsp irc channel that had no idea this mailing list even
exists or that K12LTSP for that matter, they just know LTSP and do 'yum
install ltsp' on Fedora.
They have now be educated :-)
- --
Gavin Spurgeon.
AKA Da Geek

[Les Mikesell]

Post by Jan Middelkoop
Dear list,
Gavin attended me to this mailing list in #ltsp. I didn't know of it's
existance before. For the past few days I've been eargerly following the
discussion going on here about the future of LTSP in RHEL and (more
importantly, to me) Fedora.

There are very big differences in use cases between RHEL and Fedora.
Fedora changes very quickly and to keep up you you have to reinstall
frequently. Some people like that, but I'd rather spend my life doing
something other than re-installs. working around new bugs, and finding
my hardware is no longer supported.

Post by Jan Middelkoop
Eagerly, because I've recently deployed Fedora-powered LTSP terminal
server and clients in our company and I would be very, very sad if it
were discontinued so soon. It's more than that though. I also firmly
believe that a project like LTSP is a wonderful piece of software and
deserves to be a part of Fedora.

If you don't mind not having all of this week's features in Fedora, you
can use the K12LTSP EL5 distribution. This is a respin of Centos 5.x
which will have update support for 3 more years. It uses LTSP 4,
though, which supports older hardware as terminals.

Post by Jan Middelkoop
For lack of knowledge I cannot join in on the debate about if LTSP and
remote X is technically a good solution and if there couldn't be better
ones.

You can use remote X technology a slightly different way by running the
desktop and some applications locally. Where audio and video are
involved, this is probably a better direction but authentication and
mapping remote resources are issues that don't have standard solutions.

Post by Jan Middelkoop
I do however think it seems premature to drop LTSP support in
Fedora. I don't think Fedora currently contains a piece of software that
provides the same ease of use and functionality as LTSP (correct me if
I'm wrong).

Basically anything running X can run anything remotely, including the
window manager and desktop environment. For example you can boot a
livecd version of about any linux without starting X, then start it with
"X -query remote-host" and if the remote host is configured to accept
remote logins, you get a GUI login prompt, followed by the display of
the remote desktop. LTSP is just a wrapper to network-boot machines
into that state.

Post by Jan Middelkoop
I believe LTSP brings unique functionality to Fedora. One thing I
haven't heard an alternative for in the debate going on now, is running
applications locally on the clients, yet integrating them nicely into
the desktop environment.

If the desktop hardware is really a PC capable of running its own OS,
you can run any version of X there to get the remote desktop or the NX
client from www.nomachine.com which works the same but has better remote
performance and works with freenx or their commercial server.
Personally, I use a 2-headed windows box with an NX session to a linux
server on one, local apps on the other, but there is intentionally no
integration other than being able to cut/paste text between the windows.

Post by Jan Middelkoop
Something LTSP does, with remote X. This
functionality is vital for our company. We use VoIP softphones for our
telephony needs. When I run a softphone on the LTSP server, it simply
doesn't work flawless (I've tried most, if not all). There are too many
problems with the audio. When I run the softphone locally on the clients
(cutting out the middle man), most work flawless. I cannot see
softphones performing well in a virtualized environment.

That's why I prefer to expose the difference between local and remote
apps. If I ran linux locally I'd be able to make the apps appear
seamlessly in windows in the same window manager, but I don't quite see
the point. I have always been surprised that there wasn't a good
X-oriented application menu concept to merge program launchers among
local and remote hosts, though. If there is such a thing, I've missed it.

Post by Jan Middelkoop
I try to spend around ten hours per week supporting open source
development, in one way or another. I have written documentation,
translated packages to Dutch (including LDM at one point), submitted
bugs and bugfixes, and yet... somehow I've never gotten involved with
K12Linux. Why? Because K12Linux seems distanced from Fedora. In fact,
for a long time I've had the impression that K12Linux was a Linux
distribution by itself, having LTSP readily configured for Fedora.

K12LTSP _was_ a respin, originally both in fedora and centos versions,
but eventually I think everyone gets tired of dealing with churn and
instability in fedora. It was designed to come up working with no
special technical expertise if you used a typical 2-nic configuration.
K12Linux was supposed to be the replacement based on separately packaged
applications but without a stable OS distribution it doesn't have the
same traction.

[Les Mikesell]

Post by Gavin Spurgeon
The work that I did to make the packages work on F13 was minimal, All I
did was to take to current upstream code and package it with some very
very small changes to one or 2 txt conf files.
I am sure that I/we/others could do the same with the current upstream
code on F14, F15 or even EL6/CentOS/SL6.

Can you get it into the EPEL repository for RHEL/SL/Centos? And is
there a solution for older client hardware that current Fedora and RHEL
no longer support?

[Warren Togami Jr.]

Post by Gavin Spurgeon
The work that I did to make the packages work on F13 was minimal, All I
did was to take to current upstream code and package it with some very
very small changes to one or 2 txt conf files.
I am sure that I/we/others could do the same with the current upstream
code on F14, F15 or even EL6/CentOS/SL6.

Can you get it into the EPEL repository for RHEL/SL/Centos? And is there
a solution for older client hardware that current Fedora and RHEL no
longer support?

No. There is no solution to that problem that Fedora or EPEL would accept.

Warren

[Warren Togami]

Post by Gavin Spurgeon
I am sure that I/we/others could do the same with the current upstream
code on F14, F15 or even EL6/CentOS/SL6.
I have a week of down time from my day-2-day job coming very soon, so
would have no issue trying get a very basic current upstream version
built and packaged (.rpm) ready for people to test, I had loads of
people contact me about testing the .rpm's I built for F13 and loads of
feedback for users who did play with the packages on both F13& F14.

I looked at your RPMS at http://www.dageek.co.uk/ltsp/ and noticed a
notable lack of .src.rpm's. Although it is not my intent to make Fedora
work, I want to take your minimal changes and commit them to upstream
ltsp so we don't have confusing forks.

Technically you are correct: With minimal changes F-14 could be
installable. However Fedora is highly problematic with LTSP for several
reasons. First, F-14 lacks support for the vast majority of existing
LTSP client hardware. The picture is far worse for F-15 due to big
changes in the core distro. systemd will require some LTSP surgery,
while GNOME 3 is a complete non-starter. Furthermore, Fedora's rapid
change and short support period makes it undesirable for both LTSP
development and the target deployment market. Fedora's rapidly moving
target often breaks functionality you depend on, while it is completely
untenable for organizations to upgrade their Fedora LTSP server every
year in order to keep up with security updates.

For this reason, we would be better off focusing all of our efforts on
an EL6-based LTSP server. The target deployment of LTSP wants "legacy"
desktop environments like GNOME 2. The entire stack of kernel, drivers,
desktop environment and security sensitive apps like Firefox will be
maintained for years, and largely without destabilizing changes during
that lifetime.

Yes, EL-6 based LTSP has the same client hardware support problem as
Fedora. I will do some experimentation here of both rebuilding the
entire client distro to i586 or using a Debian /opt/ltsp/i386, to
determine which requires less effort to support in the coming years.

Warren Togami
***@togami.com

[Terrell Prude' Jr.]

we would be better off focusing all of our efforts on an EL6-based
LTSP server

I couldn't agree more with Warren's reasoning here. Fedora is too
bleeding-edge for a production server that "must work". It's basically
a perpetual beta. That's why RHEL (and thus CentOS) exists.

--TP

[Rob Owens]

Warren has already recommended Debian as a viable alternative for folks
on this list. I can understand wanting to stick with Fedora and CentOS
if that's what you know best. How about this:

Use Debian as the LTSP server that boots up your thin clients. Then,
using the "next server" option in dhcpd.conf, get your GUI from a Fedora
or CentOS server of your choice. (Assuming that functionality is still
present in recent Fedora and CentOS). Or... Use VNC or something similar to
connect from a stripped-down Debian thin client to a machine of your
choice.

Both of these solutions give you the easy management of LTSP, with the
Fedora/CentOS/other user experience you might be looking for. These
solutions only add one extra server to your system, and it can be a
really, really low end system if all it's going to do is PXE boot your
thin clients.

Or you could just use Debian like Warren mentioned. I use it, and it
works nicely. The LTSP package manager for Debian is easy to get in
touch with on the ltsp-discuss mailing list.

-Rob

Post by Warren Togami Jr.
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
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Jim Kinney]

Rob,

I don't see the issue being server support of pxe boot on CentOS (or RHEL or
Fedora - cobbler is mainstreamed for all of these). The issue is the OS
available for the thin clients to use that's provided by the server. The
minimum hardware supported for Fedora is i686 so many really old i386 and
alternative cpu systems are automatically off the list.

However, Debian still supports all the way to the _real_ i386 system as well
as other very slim distros (I've tinkered with tinycore - runs in 10M ram!).

So the real work is to fix the servers so they support providing an
non-server OS to the clients.

Another issue I hit the wall on a while back was the (ab)use of flash in
almost all edu web sites. Flash has not become a lighter weight tool either.
So many teachers are wanting to use youtube and other flash video sites
(heck, all multimedia) in the classroom and for large installations, that
will bring a beefy server to it's knees when 30 clients fire up the same
video. It just doesn't scale.

So the solution that my team and I were moving towards was what we called a
"chubby client". PXE boot OS and NFS mount a full root with all binaries
(not the server OS by default). The system ran X local and thus all
application ran local, especially firefox with flash. So a single overload
would not bring down the server but just a single client. The big technical
hurdle we hit was the need to limit the tab count for firefox (or at least a
memory usage as there was no plan for swap space - that may change).

Post by Rob Owens
Warren has already recommended Debian as a viable alternative for folks
on this list. I can understand wanting to stick with Fedora and CentOS
Use Debian as the LTSP server that boots up your thin clients. Then,
using the "next server" option in dhcpd.conf, get your GUI from a Fedora
or CentOS server of your choice. (Assuming that functionality is still
present in recent Fedora and CentOS). Or... Use VNC or something similar to
connect from a stripped-down Debian thin client to a machine of your
choice.
Both of these solutions give you the easy management of LTSP, with the
Fedora/CentOS/other user experience you might be looking for. These
solutions only add one extra server to your system, and it can be a
really, really low end system if all it's going to do is PXE boot your
thin clients.
Or you could just use Debian like Warren mentioned. I use it, and it
works nicely. The LTSP package manager for Debian is easy to get in
touch with on the ltsp-discuss mailing list.
-Rob

Post by Warren Togami Jr.
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
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Rob Owens]

I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.

But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

-Rob

Post by Jim Kinney
Rob,
I don't see the issue being server support of pxe boot on CentOS (or RHEL or
Fedora - cobbler is mainstreamed for all of these). The issue is the OS
available for the thin clients to use that's provided by the server. The
minimum hardware supported for Fedora is i686 so many really old i386 and
alternative cpu systems are automatically off the list.
However, Debian still supports all the way to the _real_ i386 system as well
as other very slim distros (I've tinkered with tinycore - runs in 10M ram!).
So the real work is to fix the servers so they support providing an
non-server OS to the clients.
Another issue I hit the wall on a while back was the (ab)use of flash in
almost all edu web sites. Flash has not become a lighter weight tool either.
So many teachers are wanting to use youtube and other flash video sites
(heck, all multimedia) in the classroom and for large installations, that
will bring a beefy server to it's knees when 30 clients fire up the same
video. It just doesn't scale.
So the solution that my team and I were moving towards was what we called a
"chubby client". PXE boot OS and NFS mount a full root with all binaries
(not the server OS by default). The system ran X local and thus all
application ran local, especially firefox with flash. So a single overload
would not bring down the server but just a single client. The big technical
hurdle we hit was the need to limit the tab count for firefox (or at least a
memory usage as there was no plan for swap space - that may change).

Post by Rob Owens
Warren has already recommended Debian as a viable alternative for folks
on this list. I can understand wanting to stick with Fedora and CentOS
Use Debian as the LTSP server that boots up your thin clients. Then,
using the "next server" option in dhcpd.conf, get your GUI from a Fedora
or CentOS server of your choice. (Assuming that functionality is still
present in recent Fedora and CentOS). Or... Use VNC or something similar to
connect from a stripped-down Debian thin client to a machine of your
choice.
Both of these solutions give you the easy management of LTSP, with the
Fedora/CentOS/other user experience you might be looking for. These
solutions only add one extra server to your system, and it can be a
really, really low end system if all it's going to do is PXE boot your
thin clients.
Or you could just use Debian like Warren mentioned. I use it, and it
works nicely. The LTSP package manager for Debian is easy to get in
touch with on the ltsp-discuss mailing list.
-Rob

Post by Warren Togami Jr.
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
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

--
--
James P. Kinney III
As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as they
please, and those who survive will be left to contemplate the outcome.
- *2011 Noam Chomsky*
_______________________________________________
K12OSN mailing list
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>

[Rob Owens]

Post by Rob Owens
I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.

There's also this, which looks interesting (especially since NoMachine
stopped releasing code under a Free license).

http://www.x2go.org

-Rob

[Les Mikesell]

Post by Rob Owens
I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.
But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

You need this step to be able to find the debian kernel (etc.) to
include, then save the results where the fedora/RHEL (etc.) host can use
it as the boot image and nfs export to the client. I think there should
be some way to use a foreign-OS liveCD or image as the source so you
could update without needing a fully installed copy, but don't know
exactly what LTSP5 needs there. If it includes everything the client
side executes, you'd be able to run a 64-bit host OS and support 32-bit
clients. Maybe if the debian/ubuntu/fedora packager were the same, the
client chroot could be packaged individually and the debian/ubuntu
flavors included for fedora, but you need some sort of update plan to
handle security fixes, support for new hardware, etc.

It would also be handy to have a USB-boot version of the same thing plus
a similar version that loads an NX client to use in situations where PXE
booting doesn't work and/or you have limited bandwidth.

[Rob Owens]

Post by Les Mikesell

Post by Rob Owens
I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.
But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

You need this step to be able to find the debian kernel (etc.) to
include, then save the results where the fedora/RHEL (etc.) host can
use it as the boot image and nfs export to the client. I think
there should be some way to use a foreign-OS liveCD or image as the
source so you could update without needing a fully installed copy,
but don't know exactly what LTSP5 needs there. If it includes
everything the client side executes, you'd be able to run a 64-bit
host OS and support 32-bit clients. Maybe if the
debian/ubuntu/fedora packager were the same, the client chroot could
be packaged individually and the debian/ubuntu flavors included for
fedora, but you need some sort of update plan to handle security
fixes, support for new hardware, etc.
It would also be handy to have a USB-boot version of the same thing
plus a similar version that loads an NX client to use in situations
where PXE booting doesn't work and/or you have limited bandwidth.

I don't think you'd need a liveCD or anything (unless I'm
misunderstanding your intent). The way it works on Debian is the chroot
gets built from debs that come from the Debian repository. It can be
done with just an internet connection.

Assuming you can get the gpg trust thing worked out, a "yum install
ltsp" could grab the debs it needs from the Debian repository and
construct the chroot. It could be as simple as importing the Debian
keyring into the keyring of "root" on the Fedora system. I think that
keyring is located in the Debian package "debian-archive-keyring". I'm
not sure if the Debian keyring even needs to be known by the Fedora
system, or if it only needs to be known in the chroot.

-Rob

[Les Mikesell]

Post by Rob Owens
I don't think you'd need a liveCD or anything (unless I'm
misunderstanding your intent). The way it works on Debian is the chroot
gets built from debs that come from the Debian repository. It can be
done with just an internet connection.

If all the contents of the chroot and kernel are included as opposed to
a script that builds it from the host versions of the files, that would
work fine.

Post by Rob Owens
Assuming you can get the gpg trust thing worked out, a "yum install
ltsp" could grab the debs it needs from the Debian repository and
construct the chroot. It could be as simple as importing the Debian
keyring into the keyring of "root" on the Fedora system. I think that
keyring is located in the Debian package "debian-archive-keyring". I'm
not sure if the Debian keyring even needs to be known by the Fedora
system, or if it only needs to be known in the chroot.

I don't know much about the debian way of packaging. It is different
enough that yum isn't going to do it natively, but there are tools to
extract the contents or convert to other formats (alien?).

[Warren Togami Jr.]

Post by Les Mikesell

I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.
But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

You need this step to be able to find the debian kernel (etc.) to
include, then save the results where the fedora/RHEL (etc.) host can use
it as the boot image and nfs export to the client. I think there should
be some way to use a foreign-OS liveCD or image as the source so you
could update without needing a fully installed copy, but don't know
exactly what LTSP5 needs there. If it includes everything the client
side executes, you'd be able to run a 64-bit host OS and support 32-bit
clients. Maybe if the debian/ubuntu/fedora packager were the same, the
client chroot could be packaged individually and the debian/ubuntu
flavors included for fedora, but you need some sort of update plan to
handle security fixes, support for new hardware, etc.

Any machine that can handle the extra overhead (mainly memory) of
running a foreign LiveCD wouldn't have the problem of being unsupported
by an EL6-based /opt/ltsp/i386. So this isn't a viable solution.

Warren

[Les Mikesell]

Post by Les Mikesell

Post by Rob Owens
But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

You need this step to be able to find the debian kernel (etc.) to
include, then save the results where the fedora/RHEL (etc.) host can use
it as the boot image and nfs export to the client. I think there should
be some way to use a foreign-OS liveCD or image as the source so you
could update without needing a fully installed copy, but don't know
exactly what LTSP5 needs there. If it includes everything the client
side executes, you'd be able to run a 64-bit host OS and support 32-bit
clients. Maybe if the debian/ubuntu/fedora packager were the same, the
client chroot could be packaged individually and the debian/ubuntu
flavors included for fedora, but you need some sort of update plan to
handle security fixes, support for new hardware, etc.

Any machine that can handle the extra overhead (mainly memory) of running a
foreign LiveCD wouldn't have the problem of being unsupported by an EL6-based
/opt/ltsp/i386. So this isn't a viable solution.

I didn't mean to run the livecd on the client - or at least every client. I
meant to use it as the source of the kernel and the contents of files in the
chroot area by running a script on the server. I suppose you could also do it
client-side by using a suitable PC for the job - not necessarily one of the
usual thin clients. Once the files are extracted, they could be
packaged/redistributed if the license of the source distribution permits and the
hosting repository wants them but those are big ifs. Pulling them from directly
from the alternate distribution's iso avoids those issues and lets the end user
choose between debian and ubuntu (and maybe others) depending on which supports
your hardware better. I don't know enough about ltsp5 to know if it is supposed
to have enough of the system in the chroot to be able to do updates from its
distribution from a client, but this approach would avoid the need for that by
repeating the process as new isos are available and would let you completely
replace the client base distro with one that isn't a direct update.

An alternative might be to use a distro built for easy remastering like puppy
and maintain your own client-optimized version for the chroot (perhaps with
usb/cd versions as well) but that seems like extra work that would have to be
repeated over the life of the server - but perhaps with some advantages.

[Warren Togami Jr.]

Post by Les Mikesell

I made a mistake. "next server" in dhcpd.conf is not correct. If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X. If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.
But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense. Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

You need this step to be able to find the debian kernel (etc.) to
include, then save the results where the fedora/RHEL (etc.) host can use
it as the boot image and nfs export to the client.

That's trivial. The existing scripts in ltsp-server might already do
the job with a Debian-based chroot. Some minor changes would be
necessary to make it a smooth experience.

Warren

[Warren Togami Jr.]

Post by Rob Owens
Warren has already recommended Debian as a viable alternative for folks
on this list. I can understand wanting to stick with Fedora and CentOS
Use Debian as the LTSP server that boots up your thin clients. Then,
using the "next server" option in dhcpd.conf, get your GUI from a Fedora
or CentOS server of your choice. (Assuming that functionality is still
present in recent Fedora and CentOS). Or... Use VNC or something similar to
connect from a stripped-down Debian thin client to a machine of your
choice.
Both of these solutions give you the easy management of LTSP, with the
Fedora/CentOS/other user experience you might be looking for. These
solutions only add one extra server to your system, and it can be a
really, really low end system if all it's going to do is PXE boot your
thin clients.
Or you could just use Debian like Warren mentioned. I use it, and it
works nicely. The LTSP package manager for Debian is easy to get in
touch with on the ltsp-discuss mailing list.

I'm going to experiment with the opposite of this: EL6 LTSP server with
Debian /opt/ltsp/i386.

Warren

[Jeff Siddall]

Post by Warren Togami Jr.
I'm going to experiment with the opposite of this: EL6 LTSP server with
Debian /opt/ltsp/i386.

That sounds like a good alternative. The Debian chroot could even be
built in a Debian VM running on the EL6 server itself (ie: no
requirement for a dedicated machine just to build client images).
People who have i686 hardware can use it a pure EL6 LTSP chroot, and
older hardware chroots can be created easily made in a VM.

Jeff