Re: Debian desktop support for virtualisation
2010/6/24 Jaime Ochoa Malagón <chptma@gmail.com>:
> 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
Reply to: