Ludo Brands wrote:
http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators
Interesting.
I found that the qcow format is slowing installation a lot. The filesystem
spends more time growing the qcow disk than anything else. The raw format is
faster.
But in the case of SPARC-on-Qemu you should be able to use VNC
(specifically, Debian's vnc4server package), in conjunction
with FluxBox
as desktop/wm it's fairly lean and performs well. The machine
in front
of me is a (real) SPARC running Etch, thanks to your patches
0.9.30+2.4.2 are now running fine on it so there's a fair chance the
same would apply to an emulated system; I'm in no great hurry
to update
this system to a later OS but am overdue for going round
everything and
getting onto 2.4.4.
QEMU comes now with an integrated VNC server. The problem is that the
OPENBIOS used for sparc supports only 8 bit or 24 bit color depths while the
debian suntcx driver doesn't support 24 bits. Leaves the 8 bit which lazarus
doesn't support. VNC doesn't change that.
Yes, but that VNC is in the IP space of the host, and having multiple
sessions (e.g. multiple guests of different types, or multiple sessions
from a single guest) gets messy. I tend to use it only if the guest is
Windows, although on one version of Qemu I've got here it occasionally
screws the (Windows guest) mouse pointer necessitating a reboot.
ARM is more of a problem since vnc4server is not ported to
it, I believe
that there are some ARM-specific problems in the VNC sources.
There's a
different server that does run on it (from memory,
tightvncserver) but
it appears to be hardcoded to expect the display manager to be xdm- I
prefer gdm since it's the only one with a reliable XDMCP
implementation.
The QEMU build in VNC server for arm works well but gives you the small
resolution of the versatilepb board.
Again, running a guest (rather than host) Qemu should allow you to
specify the size, since it doesn't refer to the emulated hardware or
(the equivalent of) a BIOS or OBP. I run 16-bits as standard, I've not
checked whether that's what I actually get but visually I see no obvious
problems.
In either case you /should/ be able to connect to the system using
XDMCP, e.g. using Xnest on your local system and gdm+FluxBox on the
headless one, subject to your network setup since XDMCP is a
UDP-based
protocol which implies that broadcasts don't route well.
On both arm and sparc I'm using XFCE which is quite lean also. I noticed
very little difference in speed when running lazarus with X transported over
ssh (no windowmanager running on the guest) or running in a windowmanager.
The cpu time spent in ssh/sshd transferring the X packets roughly equals the
cpu time spent by the window manager dealing with them. The advantage of ssh
is the increased resolution/color depth. For the arm limited to 256M memory,
not running a windowmanager gives you also more precious memory.
256M? Luxury! I'm not saying that this is a sensible thing to attempt,
but Lazarus will just about run in FluxBox on a 32Mb "Slug".
However at one
time (I don't know whether this is fixed) Lazarus and some other apps
performed very badly using networked X, my recollection is that the
consensus was that there was excessive input-device polling.
I noticed that the small hints that pop up when you hover over about
anything are very costly. The cause a lot of painting and repainting.
In that case it must have been fixed. You'd have noticed :-)
I just uploaded another patch for syneditmiscclasses.pp. When you cut a text
in one unit and paste it in another unit a sigbus exception was thrown. A
char pointer cast to an integer pointer.
Thanks, I'll get it presently.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
