Well, this is an old document and in general we don't use it any more because there is the "accepted debian way" to use 32bits programs, that is with ia32-libs, and in my particular case an old copy of "ia32-apt-get" (better approach in my opinion) both could achieve the solution of the second perspective...
iceweasel in a chroot for a 32 bits plugin?... try ndiswrapper and iceweasel in 64bits... This is ancient history in amd64 land... We have stable, complete and working systems nowadays... wine use ia32-libs to run... a drive of 32 bits for cups? Ok, run it in a chroot and connect as a remote server... I prefer debian I don't even try redhat in years because I don't like many things about it... (the old redhat approach is to install both libraries 32bits and 64bits there is the same today?) On Fri, Jun 25, 2010 at 12:51 PM, kap4lin <[email protected]> wrote: > 2010/6/24 Jaime Ochoa Malagón <[email protected]>: >> Some time ago... >> >> http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html >> >> In general there is no need of it any more... > > Well, that page was last edited in 2006. So, yes we can all install a > "native" 64-bit system; but that was not the issue here! > > The multi-arch movement is yet to be seen out of the "lab > environment." It certainly is an idealistic solution; but the reality > bites! And this is where Debian (and derivatives), I feel, has (have) > fallen behind. It is amazing to see how RedHat has amalgamated the > i386 and x86_64 archs. Well, to be fare, they have paid developers and > much more of a stable system (kernel, libs, etc..) to build upon, ... > yada, yada, yada, ... > > Getting back to the pertinent point: I look at chroot in two ways: > > 1. For developers to see if their code compiles in a different > architecture. These days, vbox or vmware kind of solutions are better > suited for this, I think. > > 2. For "desktop/end" users to use (proprietary) multimedia softwares > which are only available in 32-bit. > > So, from the perspective of 2: > if it is possible to bind (read-only) /lib (and /usr/lib/ and ...) of > the host system to (say) (CHROOT_PATH)/host/lib (and /host/usr/lib and > ...) of the guest; with host's library paths included in the guest's > ld.conf, then the guest could "in principle" utilize the binaries of > the host system. > > The typical scenario that I have in mind is this: a KDE desktop user > installs 32-bit iceweasel in chroot to utilize a 32-bit plugin, but > doesn't want to install the whole KDE in chroot to be able to open a > pdf file (using okular). > > I feel that this 32-bit chroot in a 64-bit machine affects GNOME and > KDE users _asymmetrically_, but such is life. > > I am eager to see how "pain-free" schroot is. > -- > Regards > Kap4Lin > -------------------------------------- > http://counter.li.org #402424 > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: > http://lists.debian.org/[email protected] > > -- Perhaps the depth of love can be calibrated by the number of different selves that are actively involved in a given relationship. Carl Sagan (Contact) Absolute certainty is a privilege of uneducated minds-and fanatics. It is, for scientific folk, an unattainable ideal. Cassius J. Keyser Jaime Ochoa Malagón Arquitecto de Soluciones Cel: +52 (55) 1021 0774 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
