Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QEMU 7.0

qemu.org

Post reply on HN
Print view View original

11–20 of 97 posts

Re: QEMU 7.0

#11

Post by johnny22 »

pm215 wrote: post #6
yjftsjthsd-h wrote: post #2

I personally didn't find most of the list interesting, but this is nice: > RISC-V: support for KVM > RISC-V: support for ratified 1.0 Vector extension, as well as Zve64f, Zve32f, Zfhmin, Zfh, zfinx, zdinx, and zhinx{min} extensions. Always happy to see RISC-V getting fully formed:)

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major version" :-) More generally, what goes on in QEMU these days is mostly continued progression of existing work rather than sudden new developments: it's an established project making incremental improvements and following along with updates to hardware and oth…

If that's the case, I wish they'd adopt a year.month style version then! I guess i never thought about their versioning though.

Re: QEMU 7.0

#12

Post by pm215 »

johnny22 wrote: post #11
pm215 wrote: post #6

Earlier quoted context omitted.

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major version" :-) More generally, what goes on in QEMU these days is mostly continued progression of existing work rather than sudden new developments: it's an established project making incremental improvements and following along with updates to hardware and oth…

If that's the case, I wish they'd adopt a year.month style version then! I guess i never thought about their versioning though.

It was simpler to just move from "major.minor and we bump the major infrequently and semi-arbitrarily when the minor is big enough to feel unwieldy" to "bump major for first release of the year" rather than completely change the version number format.

Re: QEMU 7.0

#13

Post by jzer0cool »

joshbaptiste wrote: post #7

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

Two of the coolest piece of software might I add and continuing on strong today!

Re: QEMU 7.0

#14

Post by binwiederhier »

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!

Re: QEMU 7.0

#16

Post by jaclaz »

pm215 wrote: post #6
yjftsjthsd-h wrote: post #2

I personally didn't find most of the list interesting, but this is nice: > RISC-V: support for KVM > RISC-V: support for ratified 1.0 Vector extension, as well as Zve64f, Zve32f, Zfhmin, Zfh, zfinx, zdinx, and zhinx{min} extensions. Always happy to see RISC-V getting fully formed:)

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major version" :-) More generally, what goes on in QEMU these days is mostly continued progression of existing work rather than sudden new developments: it's an established project making incremental improvements and following along with updates to hardware and oth…

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.

Re: QEMU 7.0

#17

Post by bonzini »

jaclaz wrote: post #16
pm215 wrote: post #6

Earlier quoted context omitted.

QEMU releases are calendar-based, every four months, so "7.0" just means "first release of 2022", not "we got lots of new and shiny stuff so we bumped the major version" :-) More generally, what goes on in QEMU these days is mostly continued progression of existing work rather than sudden new developments: it's an established project making incremental improvements and following along with updates to hardware and oth…

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.

Well, x.y.0 releases are all done on April, October and December.

Re: QEMU 7.0

#18

Post by bfz »

joshbaptiste wrote: post #7

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 of staying around for chores after delivering the initial act of wizardry

Re: QEMU 7.0

#19

Post by hulitu »

vbezhenar wrote: post #3
yjftsjthsd-h wrote: post #2

I personally didn't find most of the list interesting, but this is nice: > RISC-V: support for KVM > RISC-V: support for ratified 1.0 Vector extension, as well as Zve64f, Zve32f, Zfhmin, Zfh, zfinx, zdinx, and zhinx{min} extensions. Always happy to see RISC-V getting fully formed:)

Modern computing is somewhat exciting. We finally got two competitive architectures (x86 and arm) and risc-v slowly building its momentum. This can only result in a better outcome: architectures will compete with each other and improve at faster rate; software will be forced to be cross-platform which is known to improve robustness even if you don't care about other platforms (some bugs are more likely to manifest on…

We got more than 2 competitive architechtures. There was Alpha, Sparc, MIPS, PA-RISC, ARM, X86 and POWER. Now Alpha and PA-RISC are dead, POWER and Sparc are niche, MIPS 64 is dead.
Post reply on HN