чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé <berra...@redhat.com>:
> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote: > > чт, 16 мар. 2023 г., 14:02 Thomas Huth <th...@redhat.com>: > > > > > On 16/03/2023 11.22, Andrew Randrianasulu wrote: > > > > > > > > > > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu < > randrianas...@gmail.com > > > > <mailto:randrianas...@gmail.com>>: > > > > > > > > > > > > > > > > чт, 16 мар. 2023 г., 11:31 Thomas Huth <th...@redhat.com > > > > <mailto:th...@redhat.com>>: > > > > > > > > On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote: > > > > > On 16/3/23 08:17, Andrew Randrianasulu wrote: > > > > >> > > > > >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé > > > > <phi...@linaro.org <mailto:phi...@linaro.org> > > > > >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>: > > > > >> > > > > >> Hi Andrew, > > > > >> > > > > >> On 16/3/23 01:57, Andrew Randrianasulu wrote: > > > > >> > Looking at https://wiki.qemu.org/ChangeLog/8.0 > > > > <https://wiki.qemu.org/ChangeLog/8.0> > > > > >> <https://wiki.qemu.org/ChangeLog/8.0 > > > > <https://wiki.qemu.org/ChangeLog/8.0>> > > > > >> > <https://wiki.qemu.org/ChangeLog/8.0 > > > > <https://wiki.qemu.org/ChangeLog/8.0> > > > > >> <https://wiki.qemu.org/ChangeLog/8.0 > > > > <https://wiki.qemu.org/ChangeLog/8.0>>> > > > > >> > > > > > >> > === > > > > >> > System emulation on 32-bit x86 and ARM hosts has > been > > > > deprecated. > > > > >> The > > > > >> > QEMU project no longer considers 32-bit x86 and > ARM > > > > support for > > > > >> system > > > > >> > emulation to be an effective use of its limited > > > > resources, and thus > > > > >> > intends to discontinue. > > > > >> > > > > > >> > == > > > > >> > > > > > >> > well, I guess arguing from memory-consuption > point on > > > 32 > > > > bit x86 > > > > >> hosts > > > > >> > (like my machine where I run 32 bit userspace on > 64 > > > bit > > > > kernel) > > > > > > > > All current PCs have multiple gigabytes of RAM, so using a > 32-bit > > > > userspace > > > > to save some few bytes sounds weird. > > > > > > > > > > > > I think difference more like in 20-30% (on disk and in ram), not > *few > > > > bytes*. > > > > > > > > > > > > I stand (self) corrected on *on disk* binary size, this parameter > tend > > > to be > > > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I > do > > > not > > > > have full identical x64 Slackware setup for measuring memory impact. > > > > > > > > > > > > Still, pushing users into endless hw upgrade is no fun: > > > > > > > > > > > > https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/ > > > > > > > > > > > > note e-waste and energy consumption > > > > > > Now you're mixing things quite badly. That would be an argument in the > > > years > > > before 2010 maybe, when not everybody had a 64-bit processor in their > PC > > > yet, but it's been now more than 12 years that all recent Desktop > > > processors > > > > === > > > > > > Laptops, tablets etc exist. > > > > > > > > > > feature 64-bit mode. So if QEMU stops supporting 32-bit x86 > environments, > > > this is not forcing you to buy a new hardware, since you're having a > > > 64-bit > > > hardware already anyway. If someone still has plain 32-bit x86 hardware > > > around for their daily use, that's certainly not a piece of hardware > you > > > want to run QEMU on, since it's older than 12 years already, and thus > not > > > really strong enough to run a recent emulator in a recent way. > > > > > > > Well, current qemu runs quite well, than you very much (modulo all this > > twiddling with command line switches). I think very fact it runs well > (even > > as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually > > good, and if 32-bit arm hardware can keep some codeways in working state > > for me - even better. > > The problem being debated here is not a technical one, but a question > of resource prioritization. > > It is certainly technically possible to keep 32-bit support working > indefinitely and there are certainly people who would benefit from > that, like yourself. > > The issue is that it comes at a cost to the QEMU project both in terms > of where our contributors invest their time, and in terms of what we > use our CI resources for. Both maintainer time and hardware resources > are finite quantities. > > IOW, if we continue to support 32-bit host, that means that we will > be unable to work on some other feature(s) instead. > > The question we're battling with is where to draw the line, so that > we can bring the biggest benefit to QEMU consumers as a whole. > > If we keep supporting 32-bit host, that may (hypothetically) benefit > 100 users. > > If we drop 32-bit host we might be able to develop some new features > that (hypothetically) benefit 5000 new users. > > In this illustration, it would make sense to drop 32-bit, because in > aggregate we would loose 100 users, but gain 5000 new users, meaning > a net gain of 4900. Furthermore, since QEMU is open source the users > that we drop support for, do (theoretically at least) still have the > option of continuing to use older releases. > > Now those specific numbers were totally invented, and it isn't very > easy to come up with especially accurate numbers. So we have to make > a call based on a combination of factors, our intuition, consideration > of the overall hardware market, feedback from users in response to a > deprecation announcements, and more. > > With all those factors together, at this time it is looking likely > that QEMU will be better (on aggregate) if we discontinued support > for 32-bit hosts. We know that is going to upset some users, and > we are sorry for that, but we believe more users will benefit in > the long run by releasing resources to invest in other areas. > > The sad reality faced by most open source projects is that plenty > of people are willing to complain when features are dropped or not > accepted, but far far fewer are willing to contribute to the > maintenence effort, to enable the projects to accomplish more > overall. So the project maintainers are left in an impossible > situation where they unfortunately have to make tough decisions > that leave some people disappointed. > Well, this language about "market" and "investment" not just figures of the speech, sadly? Because paid developers work on areas they paid to develop, by boss with big bucks. I think by now I am in the period when I re-evaluate possibilities and futures. I was hoping this commitment to fixing 2038 year problem was indicative of people's investment in longer-term thinking. But what kind of Linux will we see/use by 2038? One like Android today, full of binary blobs and false choices, useless without fat data connection and protected very well from their own users? Who can push back this darker future? I naturally try to report bugs I encounter and follow up on them. With slightly less mainstream hardware this means ... more than 5 minutes daily. Yes, I *do* have fun on my machines, that might involve qemu, mplayer, 86Box and gcc. I hoped my time running git snapshots of many things actually helped some users beside me. I think I like to round this with tree more links to qemu-based projects, because I think they technically interesting and show there is life outside. https://github.com/xemu-project/xemu Xbox! including some kind of GPU emulation. https://github.com/kjliew/qemu-3dfx Your lovely (possible unsecure) 3dfx! https://9to5mac.com/2022/12/23/developer-emulates-iphone-os-qemu/ url speaks for itself. So, there is some positivity, but surrounded by less-than-happy uncertainty, for me. > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > >
