On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> чт, 16 мар. 2023 г., 14:02 Thomas Huth <thuth@redhat.com>:
>
> > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > >
> > >
> > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com
> > > <mailto:randrianasulu@gmail.com>>:
> > >
> > >
> > >
> > > чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> > > <mailto:thuth@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é
> > > <philmd@linaro.org <mailto:philmd@linaro.org>
> > > >> <mailto:philmd@linaro.org <mailto:philmd@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.
Xbox! including some kind of GPU emulation.
Your lovely (possible unsecure) 3dfx!
url speaks for itself.
So, there is some positivity, but surrounded by less-than-happy uncertainty, for me.