Somewhere over China while I was ignoring the world

things happened. Anyways I built out the qemu 1.4.1 and it is horribly SLOW. I don’t know why I haven’t even begun to think about gprof or what is up with GCC 4.7.2 trying to build GLIB2 as I’m having zero luck of building out a clean version.

It takes about as long as an XT to boot MS-DOS 5, so I really don’t see this as being terribly useful to anyone.

12 thoughts on “Somewhere over China while I was ignoring the world

      • Just tried booting Fedora 18/x86_64 in qemu-system-x86_64 on a Centos 6.4 host, and it boots within seconds. I’m using -nographic though. Could it be that the graphics emulation makes it slow?

        • I need to get an ethernet cable to do more testing, just about everything is in flux @ home.. but in a good way..

          Just got back from China with a hell of a cold (not the h7n9 or whatever) and just feel out of it… With the 1.0++ versions of Qemu the SDL graphics scaling did slow things considerably, but not to the point of it taking MS-DOS a minute to boot.

          I wonder if GCC 4.7 is more so to blame on MinGW, as it has issues with headers and libs trying to build a full glib2…

          • My MinGW is 4.7.2 and it has all kinds of issues… I’ll have to see how to downgrade to 4.4.7 ….

  1. QEMU is ridiculously slow here on Debian. It’s reached XT-based performance. In the end I just started using VMWare for everything.

    On a side note, had to abuse dd to get a BeOS ISO working. BeOS was noted for confusing any emulator. As it turns out, the ISO doesn’t preserve any session information unlike like a cue sheet would, so I had rip out the BeFS partition and mount it on a second CD drive. I imagine it’d work in QEMU, but the performance was complete shite, making it unusable. But it works in VMWare!

Leave a Reply