Re: chroot64 the chroot32
On Wednesday 30 Jan 2008, Bonnel Christophe wrote: As i don't have OOO in my 32bit chroot and i don't want it, i wonder if it's possible to chroot the 64bit system into the 32bit chroot in order to use the 64bitOOO when i click on a .doc link There is more to life than OpenOffice.org . KOffice can handle .doc files, and so can AbiWord. There are tools to pull the text out of .doc files. Or, you could run a 64-bit browser to visit this .doc site. It's really the webmaster's problem, not yours. .doc is not a proper standard. If I were feeling vindictive, I'd suggest DDoS-ing the site. Maybe you could stick a link on the front page of slashdot.org, about how there is this website which is blatantly encouraging people to make pirate copies of Microsoft Office in order to view .doc files . -- AJS delta echo bravo six four at earthshod dot co dot uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
Rob Andrews schrieb: May I ask why you use a 32-bit chroot? Surely evince works just Fine(tm) for viewing PDFs in 64-bit, there's 64-bit mplayer (no 32-bit DLL support, but it covers most file formats without needing external codecs), and nspluginwrapper gives flash support to 64-bit systems. Well, I never tried chroot. But Opera and - because of Sun Java plugins - Iceweasel and Openoffice still run on my old (and much too loud) 32-bit intel 686 computer instead of the newer Amd 64 one. -- To reduce spam this address accepts only mails 'To:' subscribed lists. Zur Verminderung von Spam akzeptiert diese Adresse nur Mails 'An:' abonnierte Listen. Hans Vogelsberger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
I had a similar problem - I solved it by using 64 bit wherever possible, and moved firefox to 64 bit using nspluginwrapper to do flash etc - java however is still a problem as there doesnt seem to be a java plugin for firefox in the 64 bit builds. I couldnt think of a good way to solve it with chroots, as that would become infitite looping Anton -- Anton Piatek email: [EMAIL PROTECTED] blog/photos:http://www.strangeparty.com pgp: [0xB307BAEF] (http://tastycake.net/~anton/anton.asc) fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On Thu, 2008-01-31 at 07:17 +0100, Bonnel Christophe wrote: --snip-- And i use old hardware that have not been developped for 64bit, so i need 32bit chroot to compile the kernels, root partitions, and so on ... For example, the mvpmc or the dg632. You don't need to be running a 32-bit system in order to compile 32-bit packages. That's what GCC's -march flag is for. I use my AMD64 machine (running native 64-bit programs) to compile programs for my old Pentium machine all the time because it's a heck of a lot faster. -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Total vs per-cpu memory
This question is related to problems in running a docking computation. With big cases, RAM proves insufficient, resulting in immediate segmentation fault, so that top cannot inform. Though, from the code it is clear that memory is insufficient to rotate the object in a non-parallelized part of the program. Smaller objects do not give problems. My question is: with Tyan S2895 Thunder K8WE, two dual opterons and 1GB RAM per cpu (amd64 etch), are the 16GB available to the single cpu involved in the computation, or are 4GB available? Memory was set with shmmax: kernel.shmmax = 160 kernel.shmall = 160 sysctl -p Thanks francesco pietra Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, Jan 31, 2008 at 07:39:43AM -0800, Francesco Pietra wrote: This question is related to problems in running a docking computation. With big cases, RAM proves insufficient, resulting in immediate segmentation fault, so that top cannot inform. Though, from the code it is clear that memory is insufficient to rotate the object in a non-parallelized part of the program. Smaller objects do not give problems. Insufficient ram does not EVER cause a segmentation fault. Only buggy code causes segmentation faults. If a bad programmer simply calls malloc and doesn't check that it succeeded before using it, then you get a segmentation fault, but only because the programmer didn't write proper code. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, Jan 31, 2008 at 09:12:52AM -0800, Francesco Pietra wrote: Hi Len: I agree. However, these are no standardized codes. Actually, it is a code in development that is faced with extreme situations that could not have been in the mind of the developer. Docking a large molecule onto a protein without bias is a challenging task, that the program accomplices nicely up to a certain size of the ligand. I am pushing the program beyond the limits for which it was devised. That pushing in order to tell where the program needs to be revised. The developer is not putting together known routines, he is inventing the way to come out. Any time you see segmentation fault, the programmer made a mistake. The situation is completely irrelevant. If you don't check return codes of system calls then you made a mistake. Simple as that. That said, you are certainly able to answer my question about how RAM is used by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus are dormant. If not, the only way I can invent is to look at top -i when the ligand is large but not so large to induce segmentation fault. If it is a single system, then all ram is available in one big pool. If it is an opteron then some ram will be faster for some CPUs (that being whatever ram is connected directly is slightly faster than ram connected to another CPU, but only slightly). If you run 32bit programs, then you can have at most 3GB of ram as far as I recall with linux. Certainly no more than 4GB. With a 64bit programs you can allocate any amount of ram, as long as the system still has any left and assuming there aren't any user limits applied that could prevent you from allocating anymore. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
Hi Len: I agree. However, these are no standardized codes. Actually, it is a code in development that is faced with extreme situations that could not have been in the mind of the developer. Docking a large molecule onto a protein without bias is a challenging task, that the program accomplices nicely up to a certain size of the ligand. I am pushing the program beyond the limits for which it was devised. That pushing in order to tell where the program needs to be revised. The developer is not putting together known routines, he is inventing the way to come out. That said, you are certainly able to answer my question about how RAM is used by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus are dormant. If not, the only way I can invent is to look at top -i when the ligand is large but not so large to induce segmentation fault. Thanks francesco --- Lennart Sorensen [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 07:39:43AM -0800, Francesco Pietra wrote: This question is related to problems in running a docking computation. With big cases, RAM proves insufficient, resulting in immediate segmentation fault, so that top cannot inform. Though, from the code it is clear that memory is insufficient to rotate the object in a non-parallelized part of the program. Smaller objects do not give problems. Insufficient ram does not EVER cause a segmentation fault. Only buggy code causes segmentation faults. If a bad programmer simply calls malloc and doesn't check that it succeeded before using it, then you get a segmentation fault, but only because the programmer didn't write proper code. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Total vs per-cpu memory
On Thu, 2008-01-31 at 09:12 -0800, Francesco Pietra wrote: Hi Len: I agree. However, these are no standardized codes. Actually, it is a code in development that is faced with extreme situations that could not have been in the mind of the developer. Docking a large molecule onto a protein without bias is a challenging task, that the program accomplices nicely up to a certain size of the ligand. I am pushing the program beyond the limits for which it was devised. That pushing in order to tell where the program needs to be revised. The developer is not putting together known routines, he is inventing the way to come out. That said, you are certainly able to answer my question about how RAM is used by a single cpu in my Tyan (all 8 sets of memory occupied) when the other cpus are dormant. If not, the only way I can invent is to look at top -i when the ligand is large but not so large to induce segmentation fault. Every memory slot on an Opteron system is owned by a particular CPU socket. If there is no CPU there, then the memory won't work. If there is a CPU there, but a different CPU requires access to the memory, the one CPU can ask another CPU for access to a block of memory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On 31-Jan-2008 06:17.08 (GMT), Bonnel Christophe wrote: Because i use wine and flash. I have an etch install. I have tried to use wine 64bit but it gives me error and nspluginwrapper, after many many many different versions, i never can use it fully, a version works on a website but not on another one, the next nspluginwrapper works on the second website but not on the first ... Okay. If you have any bugs for nspluginwrapper, please do submit them to the bts because I do (hopefully) respond in a fairly timely manner. I have one fairly important bug to fix regarding thin clients, and anything core to the software itself goes upstream to the author. And i use old hardware that have not been developped for 64bit, so i need 32bit chroot to compile the kernels, root partitions, and so on ... For example, the mvpmc or the dg632. Ah, mvpmc. I used to use that on the Hauppauge MediaMVP. Can you not rebuild the ppc toolchain for 64-bit architecture? That is, if it doesn't already work with ia32-libs installed. rob. -- rob andrews :: pgp 0x5c205974 :: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On 31-Jan-2008 10:27.51 (GMT), Anton Piatek wrote: I couldnt think of a good way to solve it with chroots, as that would become infitite looping (not being rude to any chroot users...) I don't get the whole chroot thing. I ran it for a short period of time as I use Skype for work purposes, but I keep a small number of 32-bit libraries installed in my user area to run it now, rather than install an entire chroot for one application. The underlying issue is that Debian's way of handling multiarch is a little flawed (imho, of course). It would be nice if dpkg could handle multiple binary architectures on platforms that support it, and end the necessity to keep a second system installed in a subdirectory somewhere. powerpc powerpc64 being the other system that would really appreciate the loving that proper multiarch support would bring. sparc sparc64 also, but I don't know what the state of Debian sparc is these days, or even if it's still being developed. Fedora handles biarch quite well, although rpm is fairly ugly. 64-bit libraries are installed into /lib64 and /usr/lib64, whilst 32-bit is kept in /lib and /usr/lib. Common files are an issue - if you install both 32 and 64-bit libraries, then common files in /usr/share are deleted if you remove one of the architectures, meaning you have to reinstall the remaining pakage to get those files back. We could learn and improve upon this arrangement. Give dpkg multiarch support, by tracking package contents for each installed architecture. -- rob andrews :: pgp 0x5c205974 :: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On 31-Jan-2008 10:20.51 (GMT), Hans Vogelsberger wrote: Well, I never tried chroot. But Opera and - because of Sun Java plugins - Iceweasel and Openoffice still run on my old (and much too loud) 32-bit intel 686 computer instead of the newer Amd 64 one. The Java plugin is an interesting one. I don't see why the Java NPAPI plugin hasn't been ported to 64-bit systems. Konqueror uses a Java hack as far as I am aware, calling the java executable direcly and embedding it directly into an X region on the display. I wonder how hard it would be to hack a wrapper plugin to do that natively. -- rob andrews :: pgp 0x5c205974 :: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On Thu, 2008-01-31 at 19:56 +, Rob Andrews wrote: --snip-- Fedora handles biarch quite well, although rpm is fairly ugly. 64-bit libraries are installed into /lib64 and /usr/lib64, whilst 32-bit is kept in /lib and /usr/lib. Common files are an issue - if you install both 32 and 64-bit libraries, then common files in /usr/share are deleted if you remove one of the architectures, meaning you have to reinstall the remaining pakage to get those files back. This is what Debian does as well, except that we have no problem with files being overwritten by other packages. :) The only catch is, the ia32 packages have to be made and maintained by a real human for the amd64 architecture. While this is certainly something that COULD (in theory) be added to apt and friends to allow direct installs of ia32 packages, it would undermine the entire rock-solid foundation of Debian (which is based, contrary to popular belief, not on a program like apt or dpkg, but on fantastic maintainers who pay a great deal of attention to detail). While this approach does mean that not all 32-bit-only programs are available for amd64, we do have packages for the most important offenders. (Java and friends come to mind.) -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: chroot64 the chroot32
On Thu, 2008-01-31 at 19:47 +, Rob Andrews wrote: On 31-Jan-2008 10:20.51 (GMT), Hans Vogelsberger wrote: Well, I never tried chroot. But Opera and - because of Sun Java plugins - Iceweasel and Openoffice still run on my old (and much too loud) 32-bit intel 686 computer instead of the newer Amd 64 one. The Java plugin is an interesting one. I don't see why the Java NPAPI plugin hasn't been ported to 64-bit systems. Because Sun hasn't gotten around to it yet. But really, what do we expect? It's not like they've known about the issue for 5 years[1], or like anyone prior to us has mentioned it[2]. And it's not like anyone has ever done something that monumental to know how great of an undertaking it really is[3]. Those poor folks, always getting blamed like that... [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 [2] http://bugs.sun.com/bugdatabase/top25_rfes.do [3] I can't post a link since they're no longer around unfortunately, but Blackdown did (does if you can still find a copy) release a version of Java 1.4.2 YEARS ago for amd64, with a fully-functional browser plugin. In case you're not familiar with Blackdown, they were actually allowed by Sun (pre-Sun going GPL here) to hack on the Java source and release their own packages. A few years ago your only choice for a Debian package for Java was using Blackdown. (They were around before we even got things like make-jpkg, let alone the binary packages we have now.) -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837 signature.asc Description: This is a digitally signed message part
Re: Total vs per-cpu memory
On Thu, 2008-01-31 at 07:39 -0800, Francesco Pietra wrote: This question is related to problems in running a docking computation. With big cases, RAM proves insufficient, resulting in immediate segmentation fault, so that top cannot inform. Though, from the code it is clear that memory is insufficient to rotate the object in a non-parallelized part of the program. Smaller objects do not give problems. My question is: with Tyan S2895 Thunder K8WE, two dual opterons and 1GB RAM per cpu (amd64 etch), are the 16GB available to the single cpu involved in the computation, or are 4GB available? Where did 16GiB come from? I count 2x2 in the above scenario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
On Thursday 31 January 2008, Rob Andrews wrote: On 31-Jan-2008 10:20.51 (GMT), Hans Vogelsberger wrote: Well, I never tried chroot. But Opera and - because of Sun Java plugins - Iceweasel and Openoffice still run on my old (and much too loud) 32-bit intel 686 computer instead of the newer Amd 64 one. You can install the 32bit opera on amd64 using --force-architecture and some alterations of the startup script. It works (somewhat) with flash and java. There's also a beta amd64 .deb of 9.50b, which I'm planning on trying tomorrow. -Chris The Java plugin is an interesting one. I don't see why the Java NPAPI plugin hasn't been ported to 64-bit systems. Konqueror uses a Java hack as far as I am aware, calling the java executable direcly and embedding it directly into an X region on the display. I wonder how hard it would be to hack a wrapper plugin to do that natively. -- rob andrews :: pgp 0x5c205974 :: [EMAIL PROTECTED] | Christopher Judd, Ph. D. [EMAIL PROTECTED] | IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chroot64 the chroot32
Rob Andrews a écrit : On 31-Jan-2008 06:17.08 (GMT), Bonnel Christophe wrote: And i use old hardware that have not been developped for 64bit, so i need 32bit chroot to compile the kernels, root partitions, and so on ... For example, the mvpmc or the dg632. Ah, mvpmc. I used to use that on the Hauppauge MediaMVP. Can you not rebuild the ppc toolchain for 64-bit architecture? That is, if it doesn't already work with ia32-libs installed. rob. I have tried with ia32-libs but i had error. I'm not able to cross-compile on my own if the compile-method doesn't already exist. I'm not good enough in development. But I think I will try soon. Christophe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
