Live data from Hacker News

QEMU 7.0

qemu.org

31–40 of 97 posts

Re: QEMU 7.0

#31

Do you guys pronounce it Q-Emu (as in the letter Q then emu as in emulator) or kweemoo?

Personally I pronounce it "kwem-yoo" (first syllable starts like 'quest', second syllable like the second-person pronoun 'you'). But I think there are multiple pronunciations floating around...

Re: QEMU 7.0

#32
post #18

The same guy that started QEMU also started ffmpeg.. two very complex pieces of software https://en.wikipedia.org/wiki/Fabrice_Bellard

While this is true, please don't let it overshadow the tremendous work (possibly even the bulk of it by now) by subsequent maintainers. In the ffmpeg case that involved fighting a well-resourced hostile fork over a period of years, in the Qemu case I believe it means at least 10 years of additional substantial feature development. I wonder what Bellard's overall hit rate across all those projects looks like in terms…

I agree with you, but I also think it's pretty impressive that Fabrice has started multiple projects that many other people have devoted their entire careers to expanding/maintaining. Almost seems to challenge the common assertion that execution is more important than a great idea.

Re: QEMU 7.0

#33
post #24

I like QEMU a lot but VirtualBox is my goto because the cli commands work fairly reliably and simply and I'm ashamed to say the simplicity of the UX is compatible with my laziness. For server workloads KVM/Qemu is great but imho, Vbox or Fusion are the best in my experience. Does anyone know if there are Qemu wrappers with a nice UI/UX? My current use cases aside, it's amazing the number of nice use cases Qemu is mad…

> Does anyone know if there are Qemu wrappers with a nice UI/UX?

Maybe overkill depending on your use case but that's what I consider Proxmox[0] to be.

[0]: https://www.proxmox.com/en/

Re: QEMU 7.0

#34

Since QEMU devs/maintainers are lurking, i just want to say thank you for a fantastic project. I work for a company (Datto) that backs up Windows/Linux machines, which can then later be run as VMs for disaster recovery. Our product heavily relies on QEMU, and would be significantly harder to implement and maintain without it (believe me, it was built around VBox in the past). Thank you!

I work for an MSP that uses Datto to back up lots of servers and saved our bacon after the Kaseya hack! (Ironic how they're buying you now.) And I remember when you were using VBox, QEMU is much improved. Having QEMU boot up the backed-up VM to a screenshot that you can just email to us really helps prove to auditors that yes, our backups are tested! Now just replace all the spinning hard disks in your data centers with NVMe so we can get decent performance. :)

Re: QEMU 7.0

#35
post #18

Earlier quoted context omitted.

While this is true, please don't let it overshadow the tremendous work (possibly even the bulk of it by now) by subsequent maintainers. In the ffmpeg case that involved fighting a well-resourced hostile fork over a period of years, in the Qemu case I believe it means at least 10 years of additional substantial feature development. I wonder what Bellard's overall hit rate across all those projects looks like in terms…

What is a “hostile fork?”

One that have the same binary name as yours for compability reasons, but then proceeds to be not so compatible with slight command line options. Thus, made a whole lot of confusion because people didn't expect that depending on what distro they were using they could be using similar but incompatible software with the same executable filename.

Re: QEMU 7.0

#36
post #18

Earlier quoted context omitted.

While this is true, please don't let it overshadow the tremendous work (possibly even the bulk of it by now) by subsequent maintainers. In the ffmpeg case that involved fighting a well-resourced hostile fork over a period of years, in the Qemu case I believe it means at least 10 years of additional substantial feature development. I wonder what Bellard's overall hit rate across all those projects looks like in terms…

I agree with you, but I also think it's pretty impressive that Fabrice has started multiple projects that many other people have devoted their entire careers to expanding/maintaining. Almost seems to challenge the common assertion that execution is more important than a great idea.

These weren't un-executed ideas, though. I think it lines up very well with my general sense that the best way to get to a really good implementation of something is to publish one that's lacking in some way that annoys people. Then you have an idea plus something people can contribute work to improve.

Re: QEMU 7.0

#37
QEMU is absolutely incredible. I think its most undersold feature is the fact that it runs on Windows hosts[0] thanks to MinGW. This in itself isn't unique, but what is unique is that by default it runs entirely without admin privileges. I've been playing with shipping server apps as QEMU VMs and it works surprisingly well. QEMU itself is small enough (~20MB) to ship the entire thing with the app, including DLLs.

With -accel whpx you can even get pretty solid CPU acceleration. WHPX[1] is sort of like KVM for Windows, only takes a couple clicks and a reboot to enable, and ships on both Windows Home and Pro. Other than the heroes who did the actual work, we probably have Android to thank[2] for this situation.

If you're willing to get your hands a little dirty, QEMU is a fairly viable alternative to WSL or even Docker on Windows.

[0]: https://qemu.weilnetz.de/w64/

[1]: https://docs.microsoft.com/en-us/xamarin/android/get-started...

[2]: https://developer.android.com/studio/run/emulator-accelerati...

Re: QEMU 7.0

#38

Since QEMU devs/maintainers are lurking, i just want to say thank you for a fantastic project. I work for a company (Datto) that backs up Windows/Linux machines, which can then later be run as VMs for disaster recovery. Our product heavily relies on QEMU, and would be significantly harder to implement and maintain without it (believe me, it was built around VBox in the past). Thank you!

In this case, I hope your company consider some donations to this wonderful project, good for your business down the road too.

Re: QEMU 7.0

#39
post #28
post #24

I like QEMU a lot but VirtualBox is my goto because the cli commands work fairly reliably and simply and I'm ashamed to say the simplicity of the UX is compatible with my laziness. For server workloads KVM/Qemu is great but imho, Vbox or Fusion are the best in my experience. Does anyone know if there are Qemu wrappers with a nice UI/UX? My current use cases aside, it's amazing the number of nice use cases Qemu is mad…

“Does anyone know if there are Qemu wrappers with a nice UI/UX?” What operating system are you on?

Linux and MacOS

Re: QEMU 7.0

#40
post #30
post #16

Earlier quoted context omitted.

Hmmm. From the home page: https://www.qemu.org/ Latest releases 7.0.0 Apr 19th 2022 6.2.0 Dec 14th 2021 6.1.1 Dec 23rd 2021 And the "full list of releases": https://download.qemu.org/ is not any better, I think that starting from 2018 the number means (roughly) the year: 3=2018 (or also early 2019) 4=2019 5=2020 6=2021 7=2022 but I can see no evidence of a 4 month fixed interval release.

As the person who tagged v7.0.0 yesterday, I do in fact know our release cadence :-) As bonzini says, .0.0 is April, .1.0 August and .2.0 December. The x.y.1 are stable-branch releases which happen slightly more irregularly.

I don't doubt you know that cadence :), but without the additional info you just provided with the x.y.0 and x.y.1 distinction it didn't seem accurate when compared to the actual dates of the releases.

So, to clarify:

x is year (counting from 2016=1) ? (OR first release of a year gets a major version bump)

IF last digit is 0 then y is to be decoded as:

0=April

1=August

2=December

OTHERWISE IF last digit is 1 the y may (or may not) be decoded as above.

Post reply on HN