> > Has anyone tried putting together a MueKow environment
> > for Redhat Enterprise Linux? I'm running LTSP 4.1.1 right now
> > and I'm working on moving the execution of at least Firefox
> > off of the server and onto our clients. We have about 30 terminals
> > that we bought from disklessworkstations.com so far, and I'm
> > in the process of moving them from a Slackware based server to
> > a Redhat Enterprise based server. In the process, I also want to
> > move from icewm to a GNOME environment which will be eating up
> > more server CPU/mem. I'm hoping to move Firefox and possibly
> > all of GNOME over to run on the clients themselves. They have
> > 256MB of RAM, so it's definetely doable.
> >
> > Anyways, from working with LBE thus far it looks like it
> > is going to take quite a bit of time to get all of the required
> > packages added to the LBE for GNOME/Firefox. It'd be great to
> > just use rpm --root /path/to/ltsp-root -ivh /path/to/my/firefox.rpm
> >
> > On a related note, is there a site someplace that has some
> > package.def's available for building GNOME and Firefox (and other
> > apps as well) within the LBE? I've gotten the LBE all built, and
> > a custom kernel built with bootsplash support and some other custom
> > kernel tweaks. If there isn't such a place, it would really be great
> > to have a section added to the LTSP Wiki where people could post
> > their LBE package.def files, patches, etc.=20
>
> Frankly why bother?
Because as we add more thin clients, I don't want to have to
buy a new server. The move from IceWM to GNOME is mostly to gain the
accessibility features of GNOME. If there are lower "cost" alternatives
I'm definetely open to them.
> If you are running a 'desktop' for every client then adding
> firefox will be insignificant, so running as a local app is just
> pain-n-suffering without reason.
1) at present, 183 firefox processes running on the server @ ~40MB VM,
20MB of which is resident. That's approximately 3.6GB of RAM that
is being eaten up just by Firefox on the server. A quick check shows
about 500MB of RAM free on the server. It won't take many more
Firefox processes to eat that up.
2) I would REALLY like to be able to run both Firefox and the window
manager / desktop environment on the thin client. This of course
requires me to build GNOME or whichever WM/DE I end up going with
in the LBE so that I can distribute it to the clients. This was the
reason for my MueKow question. It would be much easier to just build
an LTSP client tree from the Redhat RPMs and then drop in the LTSP
bits. Doing some initial testing, I was able to get an LTSP client
tree "built" using RPM's --root option, except for some pre/post
script
failures.
3) For our environment, there are some benefits to having Firefox run
locally. With 30 thin clients distributed across 6 floors of the
library,
and printing to a central print queue that has no way of
differentiating
between users, it would be nice to be able to use the hostname of the
thin client that the job came from to put into the description of
the job
so the students know which job is theirs. There is also the auditing
benefits. Granted, there are trade-offs. But for us, the benefits
outweigh
the drawbacks.
> 256M for firefox on a THIN CLIENT is usually enough, but I can show you sites
> that will crash your client with 256M. Now you want to run the whole
> local-firefox-app
> with only 256M. Unless you are having fun, want to try this, and enjoying the
> learning save your self the pain and suffering
Our thin clients are primarily used for browsing through the library
catalog. I'm not too worried about websites crashing the clients.
I had originally asked both about MueKow and whether anyone had already
written
some package.def's for Firefox/GNOME to hopefully save myself some pain and
suffering.
It would also save me a lot of pain and suffering to be able to put my Firefox
and
GNOME patches into an SRPM rather than having to manually patch and rebuild
them every
time that there is a new version. And then do the same for the LBE, etc. etc. I
thought
that part of the whole point of MueKow was to relieve some pain and suffering.
If it takes
some pain and suffering to get there, then I think that it's well worth it.
Ryan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
