Since you are already using gutsy, have you tried Gnash, the free (as in freedom) version of flash?&nbsp; It can play youtube now, but it is still in development.&nbsp;&nbsp; Then again, so is gutsy.<br><br><br><div><span class="gmail_quote">
On 7/13/07, <b class="gmail_sendername">Gavin McCullagh</b> &lt;<a href="mailto:gmccullagh@gmail.com">gmccullagh@gmail.com</a>&gt; 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&#39;re a fair way deeper into this than I&#39;ve been but hopefully some of<br>this will help.<br><br>On Thu, 12 Jul 2007, Jim Kronebusch wrote:<br><br>&gt; &gt; So you&#39;re running 64-bit Ubuntu with 32-Bit Firefox on the server and
<br>&gt; &gt; presumably a 32-bit thin client system.&nbsp;&nbsp;I&#39;ve personally never run flash on<br>&gt; &gt; 64-bit ubuntu.<br>&gt;<br>&gt; I am running 64-bit edubuntu feisty.&nbsp;&nbsp;I have tried 32-bit flash under 64-bit firefox
<br>&gt; via nswrapper, I tried 32-bit firefox with 32-bit flash and I also tried the<br>&gt; Automatix2 install of 32-bit swiftfox with 32-bit flash.&nbsp;&nbsp;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.&nbsp;&nbsp;That may be problem (though<br>I could well be wrong).&nbsp;&nbsp;You can probably compile 64-bit pulseaudio<br>libflashsupport using the sources here:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://pulseaudio.vdbonline.net/libflashsupport/">
http://pulseaudio.vdbonline.net/libflashsupport/</a><br><br>but it&#39;s not clear to me if the adobe flash plugin will talk to the 64-bit<br>library -- I&#39;d guess not.<br><br>&gt; &gt; I&#39;d recommend you use 32-bit Ubuntu, not 64-bit.
<br>&gt;<br>&gt; I need to use 64-bit in order to recognize the 16GB of RAM (maybe more in<br>&gt; the future).&nbsp;&nbsp;Also the machine is Dual Quad Core Xeon machine so I want<br>&gt; to be sure I get the most out of the processors.&nbsp;&nbsp;I will be serving 110
<br>&gt; clients from this server so I need all the horsepower I can get.<br><br>That&#39;s not entirely true.&nbsp;&nbsp;32-bit linux can address greater than 4GB RAM<br>using PAE (Physical Address Extension).&nbsp;&nbsp;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&#39;d be lying if I said<br>I understood the details.&nbsp;&nbsp;A colleague of mine recently said he had used<br>PAE on FreeBSD and that depending on what you&#39;re doing it can work pretty
<br>well.&nbsp;&nbsp;I believe PAE has been fairly widely used in large environments.&nbsp;&nbsp;As<br>you say the cpu performance is less with emulated 32-bit, but they should<br>still be pretty quick.&nbsp;&nbsp;People have run 30-40 users with older dual single
<br>core xeons, though it&#39;s hard to know how that will scale up.<br><br>If you need flash (and java, etc.) to work well, I&#39;d be inclined to try the<br>32-bit.&nbsp;&nbsp;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.&nbsp;&nbsp;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&#39;s not a solution I&#39;d like to roll out to 110<br>users.&nbsp;&nbsp;In fairness to the ubuntu developers, it&#39;s almost impossible for<br>them to support flash at all, with no access to source and when adobe
<br>haven&#39;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>&gt; &gt; Are you running Gutsy?<br>&gt;<br>
&gt; Funny you should ask.&nbsp;&nbsp;Not at first.&nbsp;&nbsp;I have been trying to get local apps working<br>&gt; with LDAP on the server, the /opt/ltsp/i386 configured as an LDAP client and /home<br>&gt; mounted on boot and openssh server running on the client and a local firefox and flash
<br>&gt; installed into /opt/ltsp/i386.&nbsp;&nbsp;Then the server accessing firefox via ssh from the<br>&gt; client.&nbsp;&nbsp;My testing has firefox running and checking processes confirms it is running<br>&gt; from the client, but the start time for the app is simply unacceptable.&nbsp;&nbsp;So until I
<br>&gt; can get that figured out local apps aren&#39;t an option.&nbsp;&nbsp;So I read that<br>&gt; local apps are a goal in Gutsy and I was looking for a desperate fix for<br>&gt; the sound issue<br><br>You&#39;re a brave man to do experimental stuff like this with so many users
<br>=-O<br><br>Does it run okay once it&#39;s started?&nbsp;&nbsp;I suppose you must have:<br><br> - ldm runs ssh client -&gt; server<br> - firefox ssh runs server -&gt; client<br> - firefox executes on client<br> - client gets firefox libs &amp; 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.&nbsp;&nbsp;The startup time could be slowed down by:
<br><br> - plain old slow cpu on the client.&nbsp;&nbsp;What&#39;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>&nbsp;&nbsp; running ssh from command line perhaps with no X11, then with xeyes and
<br>&nbsp;&nbsp; then firefox).<br> - NFS slowness serving out the binaries.&nbsp;&nbsp;There&#39;s quite a bit you can tune<br>&nbsp;&nbsp; here -- use of NFS, changing block sizes, etc.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<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.&nbsp;&nbsp;I think it should be possible for<br>&nbsp;&nbsp; you to ssh to the client and run &quot;export DISPLAY=localhost:0&quot; so as not<br>
&nbsp;&nbsp; to send the window back to the server.&nbsp;&nbsp;You might have to run something<br>&nbsp;&nbsp; like &quot;xhost +localhost&quot; within ldm to achieve this.&nbsp;&nbsp;This is what the &quot;no<br>&nbsp;&nbsp; encryption&quot; stuff does.&nbsp;&nbsp;You could also run ssh with
<br>&nbsp;&nbsp; &#39;-c blowfish-cbc,aes128-cbc,3des-cbc&#39; so as to use a cheaper encryption<br>&nbsp;&nbsp; cipher (the ldm ssh session does this).<br><br>&gt; apt-get dist-upgrade.....I successfully (take that word with a grain of salt) upgraded
<br>&gt; a stand alone workstation to Gutsy to play with, but it appears that the Edubuntu<br>&gt; efforts must not be as far along.&nbsp;&nbsp;Apt broke all over with dependancy errors and I<br>&gt; have been screwing around trying to fix that.&nbsp;&nbsp;From what has loaded so far my clients
<br>&gt; still have the same sound issues.<br><br>The -kiosk option in ltsp-build-client installs firefox for local use.&nbsp;&nbsp;You<br>might get some clues from it as to how best to get firefox installed on the<br>clients.<br><br>
&gt; I have read success stories all over on running 32-bit Firefox w/Flash under 64-bit<br>&gt; OS, but I just can&#39;t get it to work with sound.&nbsp;&nbsp;I hate flash.<br><br>The difference is they aren&#39;t using thin clients.&nbsp;&nbsp;Until recently flash
<br>didn&#39;t work with sound on thin clients, period.&nbsp;&nbsp;Only the most recent flash<br>plugin with extra pulseaudio support added by the revolutionlinux guys<br>solved this.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://pulseaudio.revolutionlinux.com/PulseAudio">
http://pulseaudio.revolutionlinux.com/PulseAudio</a><br><br>&gt; All other apps I need work perfectly and are stable.&nbsp;&nbsp;If I could just get<br>&gt; sound working on flash I would be set.&nbsp;&nbsp;This is a major holdup up however<br>
&gt; and this is the year I am making a 100% changeover to Linux at the<br>&gt; student level and no flash will look pretty poor on my part.&nbsp;&nbsp;I might try<br>&gt; building a secondary server dedicated to running 32-bit apps next and
<br>&gt; tunnel them to the main server via ssh....in fact I&#39;ll start that<br>&gt; tomorrow.<br><br>I&#39;m not saying that can&#39;t work, but I really don&#39;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.&nbsp;&nbsp;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&#39;d try and short-cut the<br>sound using the environment variable), I&#39;d say your performance might well<br>be lower than using PAE and 32-bit ubuntu.&nbsp;&nbsp;You&#39;ll also need a lot of RAM
<br>on the secondary server if it&#39;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).&nbsp;&nbsp;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.&nbsp;&nbsp;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>