Since you are already using gutsy, have you tried Gnash, the free (as in freedom) version of flash? It can play youtube now, but it is still in development. Then again, so is gutsy.<br><br><br><div><span class="gmail_quote">
On 7/13/07, <b class="gmail_sendername">Gavin McCullagh</b> <<a href="mailto:gmccullagh@gmail.com">gmccullagh@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Jim,<br><br>you're a fair way deeper into this than I've been but hopefully some of<br>this will help.<br><br>On Thu, 12 Jul 2007, Jim Kronebusch wrote:<br><br>> > So you're running 64-bit Ubuntu with 32-Bit Firefox on the server and
<br>> > presumably a 32-bit thin client system. I've personally never run flash on<br>> > 64-bit ubuntu.<br>><br>> I am running 64-bit edubuntu feisty. I have tried 32-bit flash under 64-bit firefox
<br>> via nswrapper, I tried 32-bit firefox with 32-bit flash and I also tried the<br>> Automatix2 install of 32-bit swiftfox with 32-bit flash. All have the same error.<br><br>At the end of the day, all of these end up with you running 32-bit
<br>pulseaudio libflashsupport on a 64-bit system. That may be problem (though<br>I could well be wrong). You can probably compile 64-bit pulseaudio<br>libflashsupport using the sources here:<br><br> <a href="http://pulseaudio.vdbonline.net/libflashsupport/">
http://pulseaudio.vdbonline.net/libflashsupport/</a><br><br>but it's not clear to me if the adobe flash plugin will talk to the 64-bit<br>library -- I'd guess not.<br><br>> > I'd recommend you use 32-bit Ubuntu, not 64-bit.
<br>><br>> I need to use 64-bit in order to recognize the 16GB of RAM (maybe more in<br>> the future). Also the machine is Dual Quad Core Xeon machine so I want<br>> to be sure I get the most out of the processors. I will be serving 110
<br>> clients from this server so I need all the horsepower I can get.<br><br>That's not entirely true. 32-bit linux can address greater than 4GB RAM<br>using PAE (Physical Address Extension). This feature (as I understand it)
<br>is compiled into the linux-image-server packages on 32-bit (ed)ubuntu so<br>you should be able to address the full available RAM.<br><br><a href="http://kerneltrap.org/node/2450/7217">http://kerneltrap.org/node/2450/7217
</a><br><br>There is some performance penalty to using PAE, but I'd be lying if I said<br>I understood the details. A colleague of mine recently said he had used<br>PAE on FreeBSD and that depending on what you're doing it can work pretty
<br>well. I believe PAE has been fairly widely used in large environments. As<br>you say the cpu performance is less with emulated 32-bit, but they should<br>still be pretty quick. People have run 30-40 users with older dual single
<br>core xeons, though it's hard to know how that will scale up.<br><br>If you need flash (and java, etc.) to work well, I'd be inclined to try the<br>32-bit. I believe Java is going to be more freely distributable soon so
<br>maybe that issue will go away, but you might also need adobe acrobat<br>reader, skype, etc. One assumes they will release 64-bit linux versions at<br>some point, but who knows when. You can run 32-bit apps in 64-bit systems
<br>using these tricks, but it's not a solution I'd like to roll out to 110<br>users. In fairness to the ubuntu developers, it's almost impossible for<br>them to support flash at all, with no access to source and when adobe
<br>haven't even ported it to 64-bit yet.<br><br>My instincts with large numbers of people are generally to run with tried<br>and tested stuff to maintain stability.<br><br>> > Are you running Gutsy?<br>><br>
> Funny you should ask. Not at first. I have been trying to get local apps working<br>> with LDAP on the server, the /opt/ltsp/i386 configured as an LDAP client and /home<br>> mounted on boot and openssh server running on the client and a local firefox and flash
<br>> installed into /opt/ltsp/i386. Then the server accessing firefox via ssh from the<br>> client. My testing has firefox running and checking processes confirms it is running<br>> from the client, but the start time for the app is simply unacceptable. So until I
<br>> can get that figured out local apps aren't an option. So I read that<br>> local apps are a goal in Gutsy and I was looking for a desperate fix for<br>> the sound issue<br><br>You're a brave man to do experimental stuff like this with so many users
<br>=-O<br><br>Does it run okay once it's started? I suppose you must have:<br><br> - ldm runs ssh client -> server<br> - firefox ssh runs server -> client<br> - firefox executes on client<br> - client gets firefox libs & binaries from server over nfs
<br> - client executes firefox locally<br> - client gets firefox user profile over nfs<br> - client sends window data back to server over ssh<br> - server sends window data back to client over ldm ssh session<br><br>Off the top of my head. The startup time could be slowed down by:
<br><br> - plain old slow cpu on the client. What's the spec?<br> - lack of RAM on the client causing network swap to be used<br> - DNS pausing issues in starting the ssh session (you could test this by<br> running ssh from command line perhaps with no X11, then with xeyes and
<br> then firefox).<br> - NFS slowness serving out the binaries. There's quite a bit you can tune<br> here -- use of NFS, changing block sizes, etc.<br> <a href="http://nfs.sourceforge.net/nfs-howto/ar01s05.html">
http://nfs.sourceforge.net/nfs-howto/ar01s05.html</a>.<br> - overhead of doubled ssh encryption. I think it should be possible for<br> you to ssh to the client and run "export DISPLAY=localhost:0" so as not<br>
to send the window back to the server. You might have to run something<br> like "xhost +localhost" within ldm to achieve this. This is what the "no<br> encryption" stuff does. You could also run ssh with
<br> '-c blowfish-cbc,aes128-cbc,3des-cbc' so as to use a cheaper encryption<br> cipher (the ldm ssh session does this).<br><br>> apt-get dist-upgrade.....I successfully (take that word with a grain of salt) upgraded
<br>> a stand alone workstation to Gutsy to play with, but it appears that the Edubuntu<br>> efforts must not be as far along. Apt broke all over with dependancy errors and I<br>> have been screwing around trying to fix that. From what has loaded so far my clients
<br>> still have the same sound issues.<br><br>The -kiosk option in ltsp-build-client installs firefox for local use. You<br>might get some clues from it as to how best to get firefox installed on the<br>clients.<br><br>
> I have read success stories all over on running 32-bit Firefox w/Flash under 64-bit<br>> OS, but I just can't get it to work with sound. I hate flash.<br><br>The difference is they aren't using thin clients. Until recently flash
<br>didn't work with sound on thin clients, period. Only the most recent flash<br>plugin with extra pulseaudio support added by the revolutionlinux guys<br>solved this.<br> <a href="http://pulseaudio.revolutionlinux.com/PulseAudio">
http://pulseaudio.revolutionlinux.com/PulseAudio</a><br><br>> All other apps I need work perfectly and are stable. If I could just get<br>> sound working on flash I would be set. This is a major holdup up however<br>
> and this is the year I am making a 100% changeover to Linux at the<br>> student level and no flash will look pretty poor on my part. I might try<br>> building a secondary server dedicated to running 32-bit apps next and
<br>> tunnel them to the main server via ssh....in fact I'll start that<br>> tomorrow.<br><br>I'm not saying that can't work, but I really don't like the sound of it.<br>Firefox is I suspect, the _key_ application in most school environments.
<br>Running it in such a hackish way is probably asking for trouble. By the<br>time you spend all those extra cpu cycles on ssh tunnelling 60 firefox<br>sessions from 32-bit to 64-bit machine and then down to the clients, as
<br>well as sending the sound direct to the client (I'd try and short-cut the<br>sound using the environment variable), I'd say your performance might well<br>be lower than using PAE and 32-bit ubuntu. You'll also need a lot of RAM
<br>on the secondary server if it's going to run firefox for 80 users at a time<br>(firefox is one of the big RAM hogs that makes the main server need all<br>that RAM in the first place). If you ran both 32-bit, you might be able to
<br>use the spare machine to load balance with the main one.<br><br>I hope some of this is helpful and what way you go is of course entirely up<br>to you. These are just my instincts were I in your situation.<br><br>Good luck and let us know how you get on, this is all very interesting
<br>stuff for the list,<br><br>Gavin<br><br><br>--<br>edubuntu-users mailing list<br><a href="mailto:edubuntu-users@lists.ubuntu.com">edubuntu-users@lists.ubuntu.com</a><br>Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/edubuntu-users">
https://lists.ubuntu.com/mailman/listinfo/edubuntu-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>Please avoid sending me Word or PowerPoint attachments.<br>See <a href="http://www.gnu.org/philosophy/no-word-attachments.html">
http://www.gnu.org/philosophy/no-word-attachments.html</a>