Regarding LXDE: I decided to try it when I came in this morning. I like the look and feel of it, and the appearance customizations are good. It seems, indeed, lightweight and fast. If it is, indeed, stable, that is also good, but I'm not sure I can use it. However, after far more fiddling than should be necessary, I finally figured out how to start a terminal window without sifting through layers of menus. I do almost everything from a terminal window, and sometimes open dozens over the course of a day, so making that hard to do drives me nuts. I never did figure out how to add it to the task bar. In fact, it seems that one is limited, short of reconfiguring basic bits of the system, to a small set of pre-configured applets. We need to be able to customize what we can easily open. I realize that in many educational situations, limiting the options is a good thing, but for us it's just one more frustration, and we have plenty of those already.
So, I'm back to XFCE. It crashes, but so do Unity 2D and LXDE. The crash is due to a more fundamental video issue, not the sesssion. Not sure what the problem is. The screen just goes blank and the user is booted out to the login screen. Some screensavers cause it (Blinkbox and Molecule, to name two). When I've opened VMD and I move the display screen from one monitor to the other, it happens. When run as a local app, however, VMD works like a charm, no crashing at all. So, the issue must be somehow in the driver translation between server and client. On Thu, Dec 8, 2011 at 10:52 PM, Lachele Foley (Lists) <lf.l...@gmail.com> wrote: >> Apps. Once I activate local apps in lts.conf using LOCAL_APPS=True, >> does this mean that *any* program that the user would want to use >> needs to be installed into chroot? Or only those that I want > > Only those you want to be run on the client. Everything else happens > as usual. And, the users have to go out of their way to do anything > at all on the client (have to use the prefix "ltsp-localapps" before > each command). So, if they just type "firefox", it happens on the > server as usual, regardless what you put in lts.conf. I suspect you > can probably find a way to force their "firefox" icons to invoke > "ltsp-localapps firefox" rather than "firefox". I've not tested that, > though. > > The trouble with an app like firefox is going to be getting their > localapps firefox out to the internet. You can almost certainly make > that happen, but I expect it will take a little doing. The client > image will only see the server's dhcpd network by default. You'd need > to hook that into the local net. There are different ways that could > happen, depending a lot on how your local network is set up. It might > or might not be easy. I haven't looked a lot at doing that sort of > thing. > > > On Thu, Dec 8, 2011 at 10:21 PM, Joseph Bishay <joseph.bis...@gmail.com> > wrote: >> Hello, >> >> I'd like to ask a question about your very nice write-up for Local >> Apps. Once I activate local apps in lts.conf using LOCAL_APPS=True, >> does this mean that *any* program that the user would want to use >> needs to be installed into chroot? Or only those that I want >> utilizing the local thin client resources? >> >> IE: If I want the students to run Firefox locally on the thin client, >> I'd set Local_Apps=true, then sudo apt-get install firefox within the >> chroot. But what if the students also need access to (for example) >> Tux-Paint which is not part of the local apps installation? Can they >> still run it? >> >> Thank you very much. >> Joseph >> >> On Thu, Dec 8, 2011 at 9:36 PM, Lachele Foley (Lists) <lf.l...@gmail.com> >> wrote: >>>> I am a little confused here. You set LOCAL_APPS=true in lts.conf? >>>> Whoch programs does that force to be run on the client instead of the >>>> host? >>>> >>>> I was under the impression that I needed to install the program >>>> locally and then do "ltsp-localapps firefox". >>> >>> According to the latest manual, you have to set LOCAL_APPS=true in >>> lts.conf to use localapps. I haven't tried not doing that. Of >>> course, you only want to do this if your local machines have enough >>> computing resources to make it worthwhile. Most of the machines >>> around here don't bother because they run much faster as clients than >>> as regular computers. But, some of our work involves heavy data >>> analysis, often with heavy graphics, so we made a little cluster >>> designed to make those tasks easy for the folks who do them. For >>> those computers, local apps are worthwhile in some circumstances. >>> >>> The LOCAL_APPS=true in lts.conf doesn't force anything to be run >>> locally. Doing that merely instructs the ltsp server to allow apps to >>> be run locally if the person so desires. >>> >>> You have to install the program you want to run locally in the chroot >>> for the client image. If you only need programs that you can install >>> using something like "apt-get" or "yum install", then it's a pretty >>> trivial procedure (see link below for Ubuntu). If you need programs >>> that can't be installed that way, and if your client has sufficiently >>> different hardware from the server, and if you need the programs >>> installed for all similar clients, then you will also want to look up >>> "LOCAL_APPS_EXTRAMOUNTS" because you'll need to have a mount point you >>> can write to (you can't write to the image running your client). I >>> can elaborate if need be. >>> >>> Anyhow... assuming you get the software you want installed in such a >>> way that it is visible to the rather restricted chroot-based >>> environment delivered to the client, then you can run apps locally. >>> The default chroot is very limited -- on purpose. You don't want your >>> client bogged down by a huge image. So, for example, if I try >>> "ltsp-localapps firefox" from my command line, I am quietly returned >>> to the command line without having started firefox. If I open an >>> "ltsp-localapps xterm", and say "firefox" in the new xterm, I learn >>> the reason is "bash: firefox: command not found". However, the >>> "ltsp-localapps xclock" works because that's a standard part of the X >>> package. So, your chroot probably won't have firefox installed by >>> default. BTW, I find localapps is more likely to work or give useful >>> errors in general when called from an "ltsp-localapps xterm". >>> >>> To change what's in the chroot using apt-get in ubuntu, see below. I >>> used it (or something equivalent) with 11.10, and it seemed to work. >>> >>> https://help.ubuntu.com/community/UbuntuLTSP/UpdatingChroot >>> >>> But, do keep in mind that you don't want to bloat the client image. >>> Only install local programs into the chroot if you need to. There is >>> an alternative. Our apps are mostly scientific software, so we >>> install them into an "extra mount", where it doesn't grow the image, >>> but can still be used as a local process. So far, I've been able to >>> compile the programs using the client image but setting the install >>> location to the extra mount. I hope that keeps working... >>> >>> Just curious: are you on GigE ethernet or 100? That can make a big >>> difference in speed, particularly with graphics. >>> >>>> Where there specific things that made you choose XFCE over LXDE? I >>>> don't know which to choose =) >>> >>> I think it was about a week ago when I finally got the system stable >>> enough that I could force myself to start using it regularly. By >>> "stable," I mean I only break it once or twice a day now... :-) I >>> knew xfce from a decade or so ago, so tried it. It worked well. A >>> few days ago, I heard about lxde and thought "that sounds >>> interesting." So, I installed it. But, I haven't had the luxury of >>> making comparisons yet. Based on Rolf's statements, tho, I might try >>> it out some more. I have seen what might be instabilities in xfce, >>> but, here on the bleeding edge, it can be hard to tell which bit is >>> actually misbehaving. >>> >>> -- >>> :-) Lachele >>> Lachele Foley >>> CCRC/UGA >>> Athens, GA USA >>> >>> ------------------------------------------------------------------------------ >>> Cloud Services Checklist: Pricing and Packaging Optimization >>> This white paper is intended to serve as a reference, checklist and point of >>> discussion for anyone considering optimizing the pricing and packaging model >>> of a cloud services business. Read Now! >>> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >>> _____________________________________________________________________ >>> 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 >> >> ------------------------------------------------------------------------------ >> Cloud Services Checklist: Pricing and Packaging Optimization >> This white paper is intended to serve as a reference, checklist and point of >> discussion for anyone considering optimizing the pricing and packaging model >> of a cloud services business. Read Now! >> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> _____________________________________________________________________ >> 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 > > > > -- > :-) Lachele > Lachele Foley > CCRC/UGA > Athens, GA USA -- :-) Lachele Lachele Foley CCRC/UGA Athens, GA USA ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _____________________________________________________________________ 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
