Replies: 14 comments 60 replies
-
|
Maybe the page hasn't updated for me. But there is no news entry about the imminent removal of 32-bit packages here afaics: Edit: It might have been better to announce the removal of these packages at least a couple of weeks before starting to remove them. (That's already a very tight time frame given that we are near the end of the year which is often quite busy anyway.) |
Beta Was this translation helpful? Give feedback.
-
|
Just because everyone uses a 64-bit version of Windows, there's not automatically a benefit from compiling 64-bit binaries, unless the program uses a lot of RAM. So for the vast majority of software, the push to 64-bit makes little sense. |
Beta Was this translation helpful? Give feedback.
-
|
@MehdiChinoune wrote 1 hour ago:
I think that's misleading. The cause is not age of the machines, but rather functionality. Old machine can calculate 64-, 128- and 256-bit arithmetic/logical operations just fine, only slower.
Do you believe that's a justifiable reason to lessen spread of F/OSS in the scientific research area (on older machines)?
What I see most unrealistic here is Cygwin / MSYS2 dropping support for older Windows versions in the past when there was only little (or even no) additional effort needed to maintain them (the runtime itself) as these OSes stopped being moving targets already (IOW, their API became static forever since the EOL). @mmuetzel: I guess it's time to revisit @reactos and @midipix projects. Although I don't know how much of an effort would be required to get the 32-bit build of @midipix.
|
Beta Was this translation helpful? Give feedback.
-
I am interested in an example of the machine age leading to less accurate scientific results. My understanding was that scientific results come from computing software that does computing operations that runs on specific machine. Still seeing no relation between machine being old and the results being less accurate. Hence my frustration. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the example (I may ask you for their direct contact later). But these are two different statements. One mentions accuracy, another one mentions the speed. Do you mean that lesser accuracy is a consequence of an operator (eg. a research lab) adding timing restrictions? In that case the arguments are not about fundamental difference in accuracy, just about a fundamental difference in timing. And as this seems not to be a realtime calculations, I think we proved that your original statement wasn't very exact. IOW, the thing is more about decision to restrict the processing time. Which is very different from the question whether 32-bit software can calculate results that would be as accurate as results from 64-bit software. |
Beta Was this translation helpful? Give feedback.
-
And why would you push the users to do that? What benefit do they get from that? Not that regular users care about msys2 packages - Windows isn't Linux, most users just download the binary of a program and run it. Which is another reason this is going to fail if the intention truly is to push users to only use 64-bit applications, also because nothing stops a user from sticking to an older version of an application. |
Beta Was this translation helpful? Give feedback.
-
|
I was just wondering, is there a way to find out from Based on my past experience with the deprecation of 32-bit msys2, I only noticed that I wasn't getting any more msys updates when running pacman -Syu, and eventually went looking for the reason why and found the announcement of the deprecation. If it was only some packages, I might not have noticed, or at least it would have taken a lot longer. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
We could add a dummy package to "base", which shows a The above command is also part of the "new" docs page on updating: https://www.msys2.org/docs/updating/ |
Beta Was this translation helpful? Give feedback.
-
|
I've added the command to the news entry draft |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
there is no such law. and building one time centrally is less resource intensive then forcing other people to build multiple times, especially on shared server hardware like GHA vs desktop machines. |
Beta Was this translation helpful? Give feedback.
-
|
I think having a generic template for building for a new environment might be a good idea. It doesn't have to be 32-bit specific. |
Beta Was this translation helpful? Give feedback.
-
Surely this means that people want to keep the 32 bit binaries? |
Beta Was this translation helpful? Give feedback.
-
Not only that, but it also means that there are people willing to volunteer time/effort to keep them working. |
Beta Was this translation helpful? Give feedback.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
-
|
You have just inconvenienced the 86Box project by removing 32-bit qt5-static... our main Windows binaries are 32-bit because they perform better. We have no problem finding ways to improve the performance of 64-bit binaries but we need time, though that assuming it can be achieved and it's not simply a result of the architecture itself (longer pointers, fewer direct addressing instructions, etc.). Right now, you're basically pulling the rug from under our feet. |
Beta Was this translation helpful? Give feedback.
-
|
A lot of us just go to Jenkins by default, and we often also outright tell people to try the latest nightly build when they report issues.
That will be rectified. Though, we do also have a Discord server where we clearly tell people 32-bit binaries are preferred. |
Beta Was this translation helpful? Give feedback.
-
|
We could have taken a page out of their book when it comes to deprecating platform support. They are announcing two years in advance to drop building the kernel. |
Beta Was this translation helpful? Give feedback.
-
|
The Octave community doesn't distribute binaries of Octave in general. It only develops the source code. Binaries are made by distributors. I was hoping that Octave could move away from that exception by pointing Windows user to MSYS2. The 32-bit binary were meant to be serving as a test-bed for that. (There are probably less users. So, the impact might have been lower.) |
Beta Was this translation helpful? Give feedback.
-
|
Now that was hostile. |
Beta Was this translation helpful? Give feedback.
-
Please don't. |
Beta Was this translation helpful? Give feedback.
-
|
Some changes I've made:
What I'm planning to do:
|
Beta Was this translation helpful? Give feedback.
-
|
hm, true, that's a bit more tricky. |
Beta Was this translation helpful? Give feedback.
-
|
I have several projects designed to run either with or on old machines, and people actually use them. After running into mysterious problems with packages disappearing while working on one, I've tried the most common one people actually use, and it fails too. Please reconsider? This is going to cause me significant work. Dropping 32 bit would kinda defeat one of the major points of this particular project. |
Beta Was this translation helpful? Give feedback.
-
|
@MehdiChinoune writes:
Nothing prevents new project to have branching between old and new APIs, both having in place. |
Beta Was this translation helpful? Give feedback.
-
|
@davidgiven: Looks like we, the minority are forced to be expats here. It's just not ready yet (due to the manpower shortage, I guess). |
Beta Was this translation helpful? Give feedback.
-
I don't understand your reasoning here. If the project works, it works. If it doesn't, it doesn't. Rejecting a project because you think it might not work in the future isn't achieving anything and smells heavily of gatekeeping. Re building 64-bit on Linux: the situation there is not remotely comparable. I do not distribute Linux binaries (you didn't notice that the Autorelease workflow only targets Windows and OSX). Linux users either build from source or rely on a third party distribution to do so. WordGrinder is in most distributions and is built for a huge number of different architectuyres. Re building 64-bit on OSX: I would if I could. People ask me for it. Unfortunately I cannot find any CI build system which will do so as Apple are trying very very hard to deprecate i386 machines and all available VMs I can find don't have i386 tooling. (The same also applies to PowerPC machines. Yes, people have asked about this too.) ... Regardless of my application, there are lots of 32-bit machines around, and there are people who still want to get useful work done on them. Some of them are in actual industrial use. People need a toolchain to do support these. As far as I know, mingw is the only such toolchain with decent package support which allows building 32-bit windows binaries. If mingw drops 32-bit, then realistic development can't be done on these machines any more. Is your plan to just abandon them? Because I think that's really dangerous. |
Beta Was this translation helpful? Give feedback.
-
|
Not that weird --- there's a new LLVM C compiler for the 6502, and you should see some of the platforms Rust supports... Re Windows versions, I can't give you figures --- I don't collect statistics. The main application I'm concerned about is WordGrinder, which right now runs all the way back to XP. I do receive emails from users telling me how nice it is they can use it on old machines. Most of these machines are more modern versions of Windows, of course, but a lot of them are on 32-bit hardware. A lot of these emails come from older people. FluxEngine targets more recent machines, but it's still really convenient to run on older hardware because they have more ports than newer ones, and those of course tend to be 32-bit systems. But I don't see why that's relevant. Why did you ask?
No, you've missed my point. What I think is dangerous to promote waste, needless obsolescence, and the destruction of knowledge and history. If there was any other viable win32 toolchain, that'd be one thing, but (as far as I know --- please correct me if I'm wrong) there isn't. Once the ecosystem and tooling is destroyed, it'll never come back. |
Beta Was this translation helpful? Give feedback.
-
|
As far as I know, there are no plans from mingw-w64 to drop support for 32-bit targets. The "toolchain" is still intact. What I see here is basically arguing past each other, one side citing "waste" of cloud cycles, storage, and bandwidth producing 32-bit packages that they see as unnecessary/obsolete, and the other citing "waste" of old but still-working systems. Neither side seems convinced by the other. For me, I don't see the "wasted" cloud resources as that big of an issue, and I do still run a 32-bit Windows 10 tablet that is definitely showing its age. I also take the time and effort myself to keep building updated 32-bit msys2 packages even after this project dropped support for that (https://github.com/jeremyd2019/msys2-build32/releases/repo) - so far only msys2-runtime cannot be updated (because Cygwin upstream actively ripped out all the 32-bit support code in version 3.4 when they dropped support). In the end, if someone (or enough someones) care enough, and if the staunchly anti-32-bit members of this project cannot be convinced or overruled, something similar could happen with 32-bit MINGW packages: you can build and release packages (even solely on free github resources), and provide an additional pacman repository that people could drop into pacman.conf to get them. I hope it won't come to that though, and it sounds like there is support for restoring 32-bit packages on a case-by-case basis if downstream projects need them. Not everyone will agree on the definition of "need" however. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I misread your question. I thought you wanted to know about the old systems, not the news ones. In terms of new systems, most of my 32 bit users use Windows 10 (naturally).
You knows Windows 10 32-bit is still in active service and supported by Microsoft, right? It goes EoL in 2025 (not counting any potential LTS for enterprise users).
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@MehdiChinoune or @lazka According to Wikipedia, 32bit Windows 10 will survive like a zombie up to 2033. So, it's not too accurate in the news page saying that 32bit will somewhat die in 2-3 years. I suggest fixing it. All that being said, I dont understand the surprise of so many people here about 32bit removal. Only Windows maintains this "thing" in the mainstream OSes and as a Windows user I seriously doubt how well a machine with 4GB runs Win 10 22H2. |
Beta Was this translation helpful? Give feedback.
-
I've clarified it: msys2/msys2.github.io@306e137 |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, a little late to the party here. I recently asked a question #20090 about missing 32-bit packages, which OpenShot Video Editor uses in our build system. I wanted to share my feedback here as well. While I understand that MSYS2 might show near-zero download stats for some of these 32-bit packages, like Qt5, PyQt5, etc... 32-bit binaries produced by OpenShot's build server are still being downloaded hundreds of thousands of times, primarily in the education sector (which is famous of running ancient versions of Windows and old hardware). We don't upgrade these packages very often (due to fears like this, where packages will be gone), but there is still a very large need in the world for good 32-bit packages. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I claim ignorance for the exact setup of these 32-bit systems. All I know is people keep downloading 32-bit OpenShot, we had more than 10k downloads from Windows 7 machines in the past 30 days, and I continue to get emails from school districts wanting to run OpenShot on old computers. |
Beta Was this translation helpful? Give feedback.
-
|
Hi -- I see that the mingw-w64-i686-dtc package has just been removed. This broke QEMU's CI, which checks we can build on the 32-bit mingw platform. (This isn't the first of the packages we use that got removed -- libusb and spice also vanished recently -- but those are optional extras so we tweaked the CI to stop trying to install them. But dtc is more fundamental.) Should we see this as "MSYS2 is not actually supporting the i686 platform any more, stop using it" ? The NEWS item suggests you're only dropping "Packages which are likely not used outside of MSYS2", but I would suggest that libraries are among the things that third-parties using MSYS2 as a build target are likely to be using. |
Beta Was this translation helpful? Give feedback.
-
|
32-bit Windows is definitely pretty much on the edge of our supported platform set, certainly, though our deprecate-and-drop cycle is clearly a bit longer than yours is :-) In the interim we can build test at least on the Fedora mingw32 setup, though we would lose the runtime testing part of our CI. (I dunno about QEMU's upstream users, but MSYS2's 32-bit QEMU package clearly did have users, because one of them filed #19200 when it broke.) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
No, Window 10 32-bit is still in active support from Microsoft and will be until 2025. |
Beta Was this translation helpful? Give feedback.
-
|
@MehdiChinoune wrote 46 minutes ago:
You put it like these were all Linux distros. |
Beta Was this translation helpful? Give feedback.
-
Majority of them has become very much Windows-alike where the infamous Embrace-Extend-Extinguish (EEE) strategy is still much supported. A questionable thing to use as an argument. But yes, YMMV. |
Beta Was this translation helpful? Give feedback.
-
That is true for consumer users, but not at all for industrial users. And you keep referring to the now obsolete Windows 7 as the example of the OS for 32-bit hardware, but it's important to remember that Microsoft still supports it with current operating systems. Also --- you say that demand for 32-bit libraries comes from developers; does Mingw even have non-developer users? |
Beta Was this translation helpful? Give feedback.
-
|
For those interested in exact download stats (Apr 2023 to Feb 2024), here are the download #'s for the OpenShot Video Editor 32-bit installer. Notice that the user must really hunt for a 32-bit download on our website, as the default is 64-bit.
32-bit download stats (I was quite shocked in the # of downloads for 32-bit): |
Beta Was this translation helpful? Give feedback.
-
|
So that makes ~8%. I'm wondering how large the overlap is between 32 bit and Windows 7 users since things like Python no longer run there for example (upstream dropped support after Python 3.8, we kept it somewhat working until Python 3.10 via extra patches and reverts) |
Beta Was this translation helpful? Give feedback.
-
|
Hi all!
Your news about removing 32-bit packages was saying:
But Would it be possible to bring this package back please? |
Beta Was this translation helpful? Give feedback.
-
|
Awesome. Thanks @lazka ! |
Beta Was this translation helpful? Give feedback.
-
|
I'd suggest you think about 32bit going away eventually though. |
Beta Was this translation helpful? Give feedback.
-
|
Sure. We are discussing this on IRC just now. (you aren't on our IRC channel these days! 😢) Right now, the direction we seem to come into an agreement is that we are thinking maybe making a few GIMP 3 releases with 32-bit, so that 32-bit people at least have the option to use GIMP 3. And also to give them time to prepare by making an announcement (like we'll drop 32-bit after X micro-version releases). @Wormnest is also planning on working on a WIA plug-in to replace TWAIN soon after we release GIMP 3 (since the 32-bit TWAIN plug-in is used even in 64-bit GIMP and is one of the last big reason why we need 32-bit binaries even for our 64-bit build). Then if it pans out as we hope, we won't have a time range with no scanner plug-in (feature regression). |
Beta Was this translation helpful? Give feedback.
-
|
Joining the GIMP IRC server results in an TLS error ( |
Beta Was this translation helpful? Give feedback.
-
|
Ah yeah there are TLS issues lately, and I think admins on GIMPnet are procrastinating a bit on fixing it. We set As for the Matrix server, I can't say but anyway it's not synced with IRC anymore anyway (for a few months now, GNOME removed the IRC-Matrix bridge) and not sure if it will come back. Some devs are also on Matrix. Me I'm subscribed, but don't read. I only join when I get a notification in my inbox. Yeah I know, it's messy. 🤨 |
Beta Was this translation helpful? Give feedback.
-
Well, this tablet had some sort of hardware problem, it will no longer boot anything (its OS, usb stick, ... just goes to efi setup). So I'm less concerned about 32-bit packages than I was a week or two ago 😉 I was able to recover the 500gb hard drive in the dock, but I have not figured out yet how to get at the data on the onboard 64gb eMMC. |
Beta Was this translation helpful? Give feedback.
-
|
damn newer develop on something with hard soldered components 🤕 to many headaches when something goes wrong. |
Beta Was this translation helpful? Give feedback.
-
This is companion discussion to the recent news entry. If there are any questions let us know.
I've compiled a list of which 32bit packages were downloaded in the last week: https://gist.github.com/lazka/3a894412a32acb583cabbb89fcb11df4
Beta Was this translation helpful? Give feedback.
All reactions