←back to thread

122 points rickcarlino | 3 comments | | HN request time: 0s | source
Show context
kragen ◴[] No.45655604[source]
Ilo/Konilo is pretty cool, but I already knew that. What I didn't know about was qemu-system -nographic.

Any idea why crc is specifying a custom BIOS image? QEMU comes with a default one, right? Questions like these make me wish asciinema supported recording voiceovers.

I'm guessing that the slow text screen updates are some kind of an artifact of unoptimized UEFI implementation, and/or QEMU, because I'm pretty sure Konilo is a lot snappier than this running under Linux, even though the Ilo implementation is not a highly optimized virtual machine.

replies(2): >>45655990 #>>45662230 #
crc_ ◴[] No.45655990[source]
I'm not well versed in qemu's various options. When I didn't specify a BIOS image, it seems to be using SeaBIOS, not UEFI, and hangs on "Booting from Hard Disk...". I should be able to start doing proper videos soon; I've been slowly working towards that.

I can say that the display & overall performance is noticeably faster on the two actual computers I tested on than under qemu on my Linux system.

replies(3): >>45656002 #>>45656227 #>>45663278 #
kragen ◴[] No.45656002[source]
Thanks!

It makes sense that it would default to using SeaBIOS; QEMU has a lot of options whose defaults were more reasonable 20 years ago.

replies(1): >>45657350 #
yjftsjthsd-h ◴[] No.45657350[source]
This is a minor pet peeve of mine, actually. I would understand if qemu defaulted to BIOS booting, though I'd prefer that it try UEFI then fall back to BIOS/CSM at this point, but it's actively difficult to do UEFI on qemu; you have to actively feed it the ROM by path, and last I tried you had to include a -pflash for writable storage even if you weren't doing anything with it (thankfully this appears to have been fixed). I really wish they just let you do something like -boot-firmware=uefi,bios or such. (And again, in 2025 I really think UEFI should just be the default, with fallback to CSM/BIOS for backwards compat)
replies(2): >>45657413 #>>45660493 #
1. kragen ◴[] No.45657413{3}[source]
Maybe we should have new command names with defaults that are reasonable this decade, keeping qemu-system-i386 and the like for backwards compatibility?
replies(1): >>45657509 #
2. yjftsjthsd-h ◴[] No.45657509[source]
Like apt vs apt-get? Yeah, I could potentially go for that. Although in the case of qemu I'm not entirely convinced that we need to go that far because I think it would only take small tweaks to make the existing tool friendlier.
replies(1): >>45657540 #
3. kragen ◴[] No.45657540[source]
Yeah, exactly.

I don't think you can make those small tweaks without breaking tens of thousands of users' production setups which depend on those defaults.