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…

  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

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.