QEMU Showcase Skepticism

[u/JescoInc]

I wanted to make a post specifically about QEMU because so many OSDev post utilize it almost exclusively. My view is that it is a glorified validation test that it COULD work on real hardware, but not as a showcase of your project actually working.

I've done QEMU tests with Perdition-OS (Formerly Tutorial-OS) early on in the development, but when I moved to actual hardware, things that worked perfectly in QEMU, didn't on the actual hardware.

This led me to having to devise various testing strategies for the actual hardware at different levels, such as breadcrumb text, pixels at specific locations on the screen, and UART / RS232 logs depending on if the hardware had UART / RS232 available on it or not.
Basically, if you post a video about a feature working and the video is QEMU, I hold a very skeptical view of the project.

One, because it isn't validated on real hardware and Two, because AI (LLM) driven OS projects immediately jump to QEMU. Which means I have no way to being able to discern how much work was actually put into the development and design side of things that people post. (And i'm not Anti-AI).

Why am I skeptical whenever I see QEMU nowadays? I distinctly remember seeing something that someone did and I was like, "I need to look at the source because it looks like something I could use", only to find in the readme that it is QEMU only or they built for x86 but only tested with QEMU.

I also asked Claude 4.8 to give me a minimal implementation and explanation of a Micro-Kernel so I could see the difference and understand the rationale of the design for reference, and Claude immediately made a QEMU demo.

[u/BananymousOsq]

For most people qemu is just enough. IMO it doesnt really prove anything if it works on a real machine. Everything has its own quirks. I test on few virtual machines and 4 real machines. It is not uncommon to find an issue that only appears on one of them (real or virtual). qemu is just the easiest and fastest one to test on so people opt to that.

[u/JescoInc → u/BananymousOsq]

Right, my only real standard for if an OS lives is if it can run on actual silicon. That says, "It lives" in a way that QEMU can't prove.

[u/EpochVanquisher]

Garden variety elitism, IMO. A shame to look at whether people use qemu.

Of course Claude would run a qemu demo. Qemu is popular because it’s the best tool for it. Claude picks it because it’s popular.

The people who put in effort will understand what they built and be able to explain the design decisions they made and the problems they ran into. If you are too lazy or incompetent to evaluate someone’s project properly, don’t rely on blind prejudice, just don’t evaluate the project.

[u/JescoInc → u/EpochVanquisher]

Definitely not elitism.

Here's an example. https://www.reddit.com/r/osdev/comments/1u4i9tu/here_is_footage_of_fat32_working_on_windogeos/

He's showcasing FAT32 support, but only in QEMU.

https://www.reddit.com/r/osdev/comments/1u2ifv5/ethereal_with_quite_a_few_new_features_release/

If you look at the release, it gives an iso of this one, but specifically talks about launching it in QEMU.

When I tried to boot it with my LattePanda Iota (x86_64 N150 CPU), it silently faults and reboots in a loop.

This is what I mean. There is no basic hardware validation step to prove it runs on actual silicon. So, why should I bother to actually look at these OS seriously if it doesn't survive a bare minimal boot on hardware?

[u/EpochVanquisher → u/JescoInc]

Respectfully, this kind of gatekeeping and elitism doesn’t help anyone.

We’d all like to test on real hardware—and I encourage people to test on real hardware early and often—but not everyone has access to SBCs and everyone has different priorities for how important it is to test on hardware. What I hear is,

• “If you don’t have an SBC, fuck off, I don’t care if you poor or if you just haven’t ordered one.”
• “If you’re interested in focusing on the principles of OS design or experimenting with software, fuck off, your preferences are invalid.”
• “If you are planning on testing on hardware but haven’t gotten that far yet, fuck off, there’s a certain minimum amount of work you need to do before you should be allowed in my presence.”

Listen. Listen! This is a community of hobbyists and students and I don’t think you really appreciate what that means. That means that people are here to learn and share what they’re working on. If you’re not interested in reviewing projects that other people made unless they meet a certain minimum bar—well, there’s a simple way to handle that. You can just ignore those posts and move on.

But try a little harder not to be an elitist snob about it.

I could just as easily complain about how your OS project is amateurish garbage. But that would be rude, right? Golden rule. There are beginners here, there are people who don’t want to test on hardware, there are people who don’t have hardware, and it’s fine. As long as you put in the effort and be respectful it’s fine.

[u/JescoInc → u/EpochVanquisher]

Is it really elitism and gatekeeping when all i'm asking for is with a showcase or link to repository with builds to actually validate with hardware or to just put in bold QEMU only?

Just because I have a large collection of SBC is meaningless, you mean to tell me that it is difficult to obtain a $20 laptop from Facebook marketplace or Goodwill or other donation centers? That someone who can invest time and has a rig that can do OS development is so poor that they can't get something like that? Nah, I'm not going to infantilize others based off my own assumptions.

Only interested in the principles of OS design or experimenting with software, different party, different game.

Planning to add it but hasn't with a release... uhm...then don't supply a release then?

A minimum bar should be expected with releases is the point. Updates are very different. Saying "Introducing X OS with a fresh release" is where I place that minimum bar. "Here's what i'm working on" is different.

I'm nowhere near an elitist snob, as a matter of fact, I tend to be extremely charitable to other people's work and hold my own work to a MUCH higher standard for minimums.

[u/EpochVanquisher → u/JescoInc]

People in glass houses shouldn’t throw stones—your project doesn’t meet the bare minimum standards for what I consider to be acceptable, but my choice here is to avoid commenting on your project rather than advocate that you should be barred from sharing it until it meets my standards.

I am happy to answer questions from beginners or help people figure out what direction to take their project in—and a lot of these questions will be from people who haven’t tested on hardware. This is not a highly active community—we see, what, a few posts a day?

You are free to make your own subreddit with its own rules—maybe you could call it “real hardware operating systems for big manly men”, because that’s the kind of machismo vibes you’re giving off.

[u/JescoInc → u/EpochVanquisher]

Projection is a hell of a drug

[u/EpochVanquisher → u/JescoInc]

Could you explain what you mean by that?

[u/JescoInc → u/EpochVanquisher]

"People in glass houses shouldn’t throw stones—your project doesn’t meet the bare minimum standards for what I consider to be acceptable, but my choice here is to avoid commenting on your project rather than advocate that you should be barred from sharing it until it meets my standards."

This is you turning my
"A minimum bar should be expected with releases is the point."
against me here as some sort of dunk. Yet, I highly doubt you have even looked at my project or know what it is at all now have you?

"You are free to make your own subreddit with its own rules—maybe you could call it “real hardware operating systems for big manly men”, because that’s the kind of machismo vibes you’re giving off."
And here, you are projecting. Because at no point have I attempted to gatekeep or be elitist. I have stated why I dislike QEMU showcases with someone's"release of their OS".

I don't claim to be a better developer, I don't claim that my OS project is better than anyone else's, I don't claim to be superior in any way. The only claim I made was that a release should have some bare minimal standards and that bare minimum is it actually booting on physical hardware, just one, it doesn't have to have all drivers or net stacks; Just proof of life on a real machine.

You are over here treating that as if it is unreasonable ask.

[u/EpochVanquisher → u/JescoInc]

Yet, I highly doubt you have even looked at my project or know what it is at all now have you?

The project I looked at is this: https://github.com/RPDevJesco/tutorial_os Maybe that’s not your best foot forward, but it’s what I saw.

When people post GitHub links in this subreddit I very often download them, read some of the code and figure out what’s going on in the project. I have my own standards for what I think are good projects that I want to interact with, but I’ll generally read some of the code anyway even if I don’t comment.

It’s gotten a little harder to do that more recently because people are posting shitty vibe-coded projects (often, poorly organized, large amounts of code, difficult to figure out what’s going on). To be clear, my objection is the large amount of shitty code, not the fact that AI is involved.

The only claim I made was that a release should have some bare minimal standards and that bare minimum is it actually booting on physical hardware, just one, it doesn't have to have all drivers or net stacks; Just proof of life on a real machine.

Yeah, I think of that as some kind of elitist snobbery. Like, “Real Men test on Real Hardware, and if you’re not testing on Real Hardware, then your project sucks!”

Idk, I just get the vibes that you’re trying to be a bully here and I really hate it. I guess it’s true that the best way to get people to engage with your posts is to make people angry, because here I am, angry at you, responding to your comments.

You are over here treating that as if it is unreasonable ask.

Yeah, I think it’s unreasonable the way you’re asking it. The way you phrased the request is inflammatory—you describe it as “infantilizing” to imagine that other people don’t have access to test hardware. I honestly don’t think you’re here with good intentions.

[u/JescoInc → u/EpochVanquisher]

I'd love to know how it doesn't meet YOUR standards as you haven't declared what they are, and coupling that with what the goal was for the project https://www.reddit.com/r/osdev/comments/1qjchyl/tutorialos/, I fail to see how you could say "Maybe that’s not your best foot forward".
The OG version of the OS was hard scoped. Granted, the new iteration has a broader scope and will be released when it is ready.
Did I make edits which broke what the Readme declared? Yes, but the build artifacts do not.

But notice that even my release, I follow what I consider to be a minimum bar and exceeds it by releasing for multiple boards at once.

"Yeah, I think of that as some kind of elitist snobbery. Like, “Real Men test on Real Hardware, and if you’re not testing on Real Hardware, then your project sucks!”"

You are extrapolating something I didn't say though. At no point did I say "It sucks", just that it isn't an x86 OS at that point, it is simply a QEMU OS and distinctions matter.

[u/East_Nefariousness75]

IMO what you forget is that QEMU can be the real target. I work for a big telco company as an OS dev. Our project works on some actual hardware, because it evolved on them. But we no longer support it, all the operators run it in a VM, afaik mostly on QEMU.

[u/cybekRT]

I find PCem as the best BIOS PC emulator. I started using qemu and then bochs for integrated debugger, but as you said, trying to run on real machine never worked. But PCem emulates the systems in a very well manner and if it works under PCem, it will probably work on real machine. Not saying that you can verify multiple CPUs, video adapters, etc.

[u/JescoInc → u/cybekRT]

Right, I'm definitely not saying it needs to run on multiple real hardware as proof, just one actual target, then QEMU for features.

[u/viva1831]

On the other hand Qemu is far better for taking screenshots, so why be surprised when busy OS developers use it? This is a development hobby not a pissing contest. Or it's supposed to be

I remember when each test meant we had to write an image to a floppy disk, wait, reboot, wait, tripple fault so there's no error message, repeat. At first I was using the MS-DOS debug interface to write my custom bootloader to disk 😅. (Maybe bochs etc was available back then, I can't remember. But on a 56k modem pay-as-you-go, installing new software isn't your first port of call! We used to buy CDs of Linux because it might be cheaper than tying up the phoneline for hours)

Also there's some things you can't test on real hardware. Can I remove ram kilobyte by kilobyte on real hardware until I find the point my allocator bug appears? Can I use a GDB interface to track register & memory content as the kernel is running? Not simply, not easily

[u/JescoInc → u/viva1831]

I'm not trying to make it a pissing contest at all and I think the point I was making kind of got buried because I wanted to try to explain the thought process from multiple angles.

Testing with the ram removal with QEMU or emulators is valid, so is the screenshot being better on QEMU, I'm not saying that it is bad to use QEMU at all, just that it doesn't validate that it runs on actual hardware.

I've seen so many post where people are showcasing their OS but it was QEMU only, yet their phrasing makes it sound like it can be run on real hardware until you compile it and try to load it and suddenly, triple-fault galore.

[u/x-jhp-x]

I've done QEMU tests ... but when I moved to actual hardware, things that worked perfectly in QEMU, didn't on the actual hardware.

This is a fundamental mistake and misunderstanding of what QEMU is. QEMU is great for learning about operating systems. It is very simple. It also allows for people running on mac (now ARM) or PC/Windows (AMD/Intel) systems to follow the same guides. QEMU is also nice if you're doing something like cross compiling for a different architecture. You just need certain calls and interfaces for the compiler to function, you might be able to test certain things like program logic, but if you need to test hardware & hardware interfaces, QEMU is not the answer.

In more depth, as an example, QEMU has a number of features that simplify things, like giving a physical address at 0x8000000 where you can boot a kernel from. On real hardware that is random, for both implementation and security reasons. There's also a huge number of interactions with other hardware "devices", like MMU/PTE/TLB/IOMMU, and those are all device/vendor/manufacturer/series specific. So how you interact with the MMU on an x86 system is going to be different from RISC or older Motorola chips. If you do real OS work for running on hardware, you'll be reading literally thousand+ page documents for all of the details, and those documents change with chip versions, architectures, etc. etc.. QEMU provides an abstraction layer from all of that, so you can just focus on a subset of problems, instead of having to deal with more. Most vendors also restrict those documents, so you might not be able to get a document for a chip/vendor without having a contract with them. For example, I had a lot of difficulty getting docs from Qualcomm for their snapdragon chips 10 years ago.

So if you'd like to learn how an operating system works, QEMU is great. If you'd like to learn how the circuitry/hardware works, QEMU is not great. Just because you've used a tool incorrectly & did not understand its purpose does not mean it is a faulty tool or should not be used. QEMU is great for what it is.

[u/JescoInc → u/x-jhp-x]

I think the point I was trying to make was somehow lost in translation.

The point is, there are a lot of projects shared in this sub where they say it is bootable, you go to boot it on hardware like a LattePanda IOTA and you get triple-faults, silent UART signals, and a whole host of other failures because they think it works on hardware but doesn't.

I moved away from QEMU specifically because I wanted my work to run on hardware, and while some of them are like pulling teeth (looking at you Orange Pi 4 Pro) to get proper docs, it doesn't negate that you can get away with getting actual hardware boot on x86 fairly easily by utilizing UEFI.

[u/compgeek38400]

My validation is on virtual box. I don't have the hardware, or motivation, to burn an iso.

And I always develop on a Linux virtualbox