[Fwd: Re: [Ltsp-developer] "Stateless Linux"]

[Mark McLoughlin <markmc redhat com>]

--- Begin Message ---

• From: "David L. Parsley" <parsley linuxjedi org>
• To: Mark McLoughlin <markmc redhat com>
• Subject: Re: [Ltsp-developer] "Stateless Linux"
• Date: Fri, 17 Sep 2004 11:13:58 -0400 (EDT)

Hi Mark,

First, I didn't CC: ltsp-devel because I'm the developer of a competing project (Tao Linux, Thin Client Edition, http://taolinux.org/tao_tc) and consider it bad taste to 'advertise' on Jim's list. ;-)

Second, my work focuses around large numbers of desktop-bound workstations in a University setting; secretaries, labs, faculty & staff (myself included).

I've been doing Linux-based thin client development off and on for about 8 years now. For about 5 years, I've been using a Linux-based thin client as my primary desktop machine at home and work. So, I thought I'd go ahead and respond to your query. This e-mail is kind of long, though; it's similar in scope to Havoc's PDF.

On Wed, 15 Sep 2004, Mark McLoughlin wrote:

 2) to ask for feedback on the approach we're taking - its likely LTSP
    developers have plenty of insights to share on this

Ok, I'll be honest - I'm going to shoot it down pretty hard. I read the PDF paper on Stateless Linux by Havoc, and while it may produce some useful technologies, and have some administrative benefits, it comes nowhere close to the economic value of a true thin client. Havoc says 'thin clients have come in and out of fashion' - not really true; only media coverage has come and gone, but I've seen usage steadily increase (based on my professional contacts in higher ed). I'm almost ashamed to say this, but when I showed a Linux-based Windows TS client to my department, with full 16-bit color and sound, they were very excited, and we're piloting those this semester. Now that RDP supports connections to local media (usb key, floppy), that means there's a good chance I can incorporate support for local media in my next version of Tao-TC; this will more than double the number of feasible locations for this technology.

The thing is, I can build a Linux-based Windows terminal for $200, including (soon to be supported) USB ports. I've hacked anaconda to create an 'installer' for terminal hardware, so setting them up has gotten really easy.

Now, I confess the only reason I'm so excited about building Windows terminals is because it legitimizes the time I spend at work on Tao-TC development. My real target, naturally, is building the best _Linux_ terminal.

Here are the economic disadvantages I see with SL:

- The client hardware requirements are too great, and too complex. The client needs enough power to run OO.o, Mozilla, eclipse, etc all locally; and a local disk for caching to get decent performance. With my $200 terminal with only 256M ram and a 1.6GHz Duron, I can run all these programs on the server and get _GREAT_ performance. -> With a properly sized server, thin clients are much cheaper and much faster than a PC (SL client) costing 4 times as much.

(note that most of that RAM is used by X, I run 7 desktops on a 1280x1024
LCD w/ 24-bit color)

- The three big benefits of server-centric computing are gone:

1) Memory sharing amoung multiple copies of the same app; SL greatly increased the global RAM requirements. In the thin client approach, memory sharing is maximized on the server, and client memory is used appropriately for the bulk of per-user state memory that can't be shared (X window).

2) Application load time & I/O performance. An appropriately sized server will have enough RAM not only for the required per-user memory requirements, but to have most applications hot in cache w/o having to be read from disk; in the event they need to be loaded from disk, servers can be connected to much faster and more expensive disks for much faster I/O. (Can you imagine a farm of terminal servers plugged into an IBM SAN?)

3) Generally low CPU utilization by most applications. 25 users running a typical office/workstation load on a server will still leave the CPU mostly idle. For multimedia, my approach is to ship the raw data to a media service on the client for playing ogg, dvd's, etc.

So, overall, thin-client computing where the client only runs a few graphical and media services is clearly much less expensive than the SL approach. Now, SL obviously addresses laptops and disconnected operation; still, the vast majority of people working with computers in their jobs are sitting in an office using a desktop-bound machine. So, IMHO, support for laptops and disconnected use doesn't merit throwing out the advantages listed above.

What Linux needs to compete with is Microsoft Terminal Services. With Win2k3, they've made some huge leaps forward with color, sound, and device forwarding. Where they're lacking is in multi-media; you just can't play movies with TS, and mp3 players _do_ use significant server CPU resources. Because I can build an arbitrarily rich Linux client, I could, for instance, use gstreamer and RTP to ship compressed multimedia over the network for playing on the client (I'll be working on that this year).

In fact, most of the drawbacks to thin clients are just a SMOP (Simple Matter Of Programming). Unfortunately, there are too few of us working on Linux thin clients. My goal is to make Tao-TC _so_ easy to use and _develop_, that I'll be able to turn some heads and attract other developers. The anaconda-based installer and out-of-the-box sound support are big steps in this direction. IMHO, LTSP is still just too darn hard to set up and use - nevertheless, it's still VERY popular! I'd say it's because of the economics. LTSP focuses more on enabling REALLY cheap (used) hardware; when you can run OO.o sitting at a $50 machine, it's compelling. My focus is on closing the usability gap between thin clients and PC's using pretty darn cheap hardware.

Here are the technologies I'd most like to see developed for enabling Linux thin-clients:

- Network transparency of the GNOME desktop, with minimal requirements for the client. I should be able to transparently run gnomemeeting on the terminal, and it should be able to contact my running gconfd on the server for preferences, and get the font glyphs it needs loaded into the X server.

- Network transparency of the GNOME vfs, also with minimal client requirements. I'd like to be able to easily use a usb key on the terminal, or burn a cd in a terminal-connected drive.

- A gstreamer-based 'media server' in similar fashion to the X server, for sending raw media over the network to be played on the client side (where most appropriate).

Now, I'd say I'm a fairly talented programmer/hacker, but I just don't have the time and skill base to accomplish all of the above on my own. For instance, I know virtually -0- about GNOME/corba programming, so I'd have a few weeks learning curve before even starting to tackle the first two items listed (time I don't have). Fortunately, from the time I've spent with gstreamer, I know that it totally ROCKS. ;-) The features I need don't seem to be working well in the RHEL3 codebase, but when I move to the Fedora codebase for the next version of Tao-TC, I should be able to manage some flashy/impressive results - hopefully enough to attract the talent for doing the first two items. ;-)

I really, REALLY hope that the powers that be at Red Hat recognize the compelling economics of Linux-based thin client computing, and will devote some resources to developing the technologies listed above, as well as making thin clients easier to build & deploy. I figure either RH or IBM will do this in the next couple of years.

I'd be happy to make a trip to NC for More Bandwidth on this subject, and show my work so far and talk about my current development directions.

Thanks for your time. ;-)

regards,
	David

--
David L. Parsley
Network Systems Administrator, Alfred University
"If I have seen further, it is by standing on ye shoulders of giants."
	- Isaac Newton

--- End Message ---