Goswin von Brederlow wrote: > The problem is that many programs have data files in /usr/share or > /usr/lib/package or even config in /etc/. All those files will be > inside the chroot ... Yes. > ... instead of outside when you run the program outside. Any program that needs to be *installed* will need to run from the chroot. Agreed. But any program that can simply be run can be run either place. Many (most?) random programs can be run outside the chroot. It really depends upon what it is you are trying to do. > So the number of programs you can run outside is somewhat limited. I think this is just a difference in world view between your environment and mine. In mine only those two binary packages I mentioned really need to run in the chroot. A short list. Just openoffice and firefox. In the chroot. Done. However outside the chroot I have hundreds of CAD/EDA programs that are legacy 32-bit applications. They run from an NFS fileserver. They don't actually ever get "installed" on the local machine[1]. But the binaries are run just the same. That does not even mention the random programs that users would use from their $HOME directory or copy to /usr/local/bin. The list is open ended. The choice would be a 32-bit OS to be able to run those programs. Except that amd64 can run both 32-bit and 64-bit applications transparently. That means I can also benefit from the large memory model available in 64-bit for the smaller number of 64-bit CAD/EDA programs that need it. A good result. Another alternative I am working through the details for right now is the exact reverse. A 32-bit base system with a 64-bit /emul layer. Then the small number of programs that need the larger memory space run transparently. But in general the system is simpler to administer for the casual user in my lab. > I see the point of having a chroot to install lib packages and then > install binaries (with --force-arch for example) outside the charoot > or something. But in general it doesn't always work. Not something for > the faint of heart. I never use --force-arch and would advise against doing that. (shudder) I agree that having a multi-root system is more complicated than having a single-root system. I agree that some people will be confused by it beyond being able to administer one well. So I also would not recommend it for everyone. But for most system administrators it is a useful tool in the toolbox. One that I use to good effect daily. Bob [1] CAD vendors usually "install" their software in a shared filesystem location. Their installation processes are usually terrible shell scripts written without any real thought. Someone at the vendor wrote the script to just slams files out into a directory somewhere and they expect you to be able to run them on your machine. We have 30+ different applications all with completely different processes to manage them. No thought is given to system dependencies such as required libraries or programs. Well, actually they just say all of the world is a VAX, er I mean all of the world is MS-Windows, er I mean all of the world is RHEL3.0. You get the idea. People like myself who administer these environments just deal with it.
Attachment:
signature.asc
Description: Digital signature