Bugzilla – Full Text Bug Listing
|
Description
Andrey Loskutov
What's the ratio of 32-bit linux to 64-bit linux downloads / installs / startups? Same question for 32-bit windows to 64-bit windows? Here are our stats for the installer downloads: For Photon: eclipse-inst-win64.exe 220462 eclipse-inst-linux64.tar.gz 25901 eclipse-inst-mac64.tar.gz 22850 eclipse-inst-win32.exe 5729 eclipse-inst-linux32.tar.gz 523 For Oxygen (some older downloads are likely excluded, but ratio should stay roughly the same): eclipse-inst-win64.exe 886472 eclipse-inst-linux64.tar.gz 90316 eclipse-inst-mac64.tar.gz 79794 eclipse-inst-win32.exe 22578 eclipse-inst-linux32.tar.gz 1890 That looks like what I'd expected. 80% win64, 9% lin64, 8% mac64, 2% 32-bit: Here's the same data in csv format w/ percentages added: photon eclipse-inst-win64.exe 220462 80.03% photon eclipse-inst-linux64.tar.gz 25901 9.40% photon eclipse-inst-mac64.tar.gz 22850 8.30% photon eclipse-inst-win32.exe 5729 2.08% photon eclipse-inst-linux32.tar.gz 523 0.19% oxygen eclipse-inst-win64.exe 886472 82.00% oxygen eclipse-inst-linux64.tar.gz 90316 8.35% oxygen eclipse-inst-mac64.tar.gz 79794 7.38% oxygen eclipse-inst-win32.exe 22578 2.09% oxygen eclipse-inst-linux32.tar.gz 1890 0.17% Based on those numbers, I'd say support for 32-bit should be dead, as demand for 32-bit is as good as dead. Sure, 30,720 peopl (of 1,356,515 total) might disagree, but are they the ones willing to DO the work? Doubtful. :D Linux 32 is probably deader than your figures suggest since the small figures are bloated by: - typos loading the wrong distro - redistributors/researchers/spiders that download whatever is available - users who can easily migrate Are you considering RCP based products too? For example the RCP version Memory Analyzer 1.7, released on June 28 2017, was based on Mars versions of Eclipse and had this many downloads from June 28 2017 to June 27 2018. /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-win32.win32.x86_64.zip 118903 58.67% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-macosx.cocoa.x86_64.zip 41410 20.43% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.x86_64.zip 19536 9.64% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-win32.win32.x86.zip 19267 9.51% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.x86.zip 2747 1.36% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.ppc64.zip 554 0.27% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-aix.gtk.ppc64.zip 175 0.09% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.ppc64le.zip 15 0.01% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.ppc.zip 14 0.01% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.s390x.zip 11 0.01% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-linux.gtk.s390.zip 4 0.00% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-aix.gtk.ppc.zip 4 0.00% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-hpux.gtk.ia64.zip 3 0.00% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-solaris.gtk.x86.zip 3 0.00% /mat/1.7/rcp/MemoryAnalyzer-1.7.0.20170613-solaris.gtk.sparc.zip 3 0.00% For 1.8 we moved up to a Photon base, so we had to drop many OS versions as they didn't exist in the Photon base: /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-win32.win32.x86_64.zip 3035 58.48% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-macosx.cocoa.x86_64.zip 1145 22.06% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-linux.gtk.x86_64.zip 545 10.50% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-win32.win32.x86.zip 399 7.69% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-linux.gtk.x86.zip 42 0.81% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-linux.gtk.ppc64.zip 19 0.37% /mat/1.8/rcp/MemoryAnalyzer-1.8.0.20180604-linux.gtk.ppc64le.zip 5 0.10% 7 records found. 5190 For Memory Analyzer the users probably are sophisticated enough to have a 64-bit system available somewhere, but perhaps they want to run MAT on the same system that generated the dumps, which could be a 32-bit system, to avoid moving a 1GB dump. I don't know though. (In reply to Ed Willink from comment #4) > Linux 32 is probably deader than your figures suggest since the small > figures are bloated by: > > - typos loading the wrong distro > - redistributors/researchers/spiders that download whatever is available > - users who can easily migrate Yep. I think the numbers are clear, and so far no one committed to *support* 32 bit Linux. @Alex: are there any Red Hat specific plans to continue investment into 32 bit Linux Eclipse builds? Any objections from your side? @Dani: next step: PMC discussion? I saw you forwarded the mail to the PMC list. (In reply to Andrey Loskutov from comment #6) > (In reply to Ed Willink from comment #4) > > Linux 32 is probably deader than your figures suggest since the small > > figures are bloated by: > > > > - typos loading the wrong distro > > - redistributors/researchers/spiders that download whatever is available > > - users who can easily migrate > > Yep. > > I think the numbers are clear, and so far no one committed to *support* 32 > bit Linux. > > @Alex: are there any Red Hat specific plans to continue investment into 32 > bit Linux Eclipse builds? Any objections from your side? We don't plan any special work towards 32 bit x86 builds. IMHO, if there are big issues with these builds they should not be promoted to downloads but sources kept for some period so people can jump in if they are interested. > > @Dani: next step: PMC discussion? I saw you forwarded the mail to the PMC > list. (In reply to Alexander Kurtakov from comment #7) > We don't plan any special work towards 32 bit x86 builds. IMHO, if there are > big issues with these builds they should not be promoted to downloads but > sources kept for some period so people can jump in if they are interested. +1. It was discussed in Eclipse PMC and there is agreement that keeping and investing in 32 bit doesn't make sense for the current contributors. Exact date when builds are to be stopped is TBD but it also depends on such issues - if such an issue is here and no one is interested in fixing it, it might be best to drop it even for 4.9. (In reply to Alexander Kurtakov from comment #9) > It was discussed in Eclipse PMC and there is agreement that keeping and > investing in 32 bit doesn't make sense for the current contributors. Exact > date when builds are to be stopped is TBD but it also depends on such issues > - if such an issue is here and no one is interested in fixing it, it might > be best to drop it even for 4.9. Perfect. We have already two bugs reported for 4.8, see bug 536764 and bug 527536. Is this enough to stop building 32 bit on Linux? (In reply to Andrey Loskutov from comment #10) > (In reply to Alexander Kurtakov from comment #9) > > It was discussed in Eclipse PMC and there is agreement that keeping and > > investing in 32 bit doesn't make sense for the current contributors. Exact > > date when builds are to be stopped is TBD but it also depends on such issues > > - if such an issue is here and no one is interested in fixing it, it might > > be best to drop it even for 4.9. > > Perfect. We have already two bugs reported for 4.8, see bug 536764 and bug > 527536. Is this enough to stop building 32 bit on Linux? I would bring it on the next week call and it would be nice if you can offload from me the task for asking on swt-dev and cross-project if anyone is ready to object to the removal with manpower to fix issues. (In reply to Alexander Kurtakov from comment #11) > I would bring it on the next week call and it would be nice if you can > offload from me the task for asking on swt-dev and cross-project if anyone > is ready to object to the removal with manpower to fix issues. It took some time until I was at the middle of my inbox :-), but now I've sent the mails as requested. (In reply to Alexander Kurtakov from comment #11) > (In reply to Andrey Loskutov from comment #10) > > (In reply to Alexander Kurtakov from comment #9) > > > It was discussed in Eclipse PMC and there is agreement that keeping and > > > investing in 32 bit doesn't make sense for the current contributors. Exact > > > date when builds are to be stopped is TBD but it also depends on such issues > > > - if such an issue is here and no one is interested in fixing it, it might > > > be best to drop it even for 4.9. > > > > Perfect. We have already two bugs reported for 4.8, see bug 536764 and bug > > 527536. Is this enough to stop building 32 bit on Linux? > > I would bring it on the next week call The PMC decided - as it already did last week - that the removal will happen with 4.10 and not 4.9. We will also drop Windows 32-bit support. Can we start on this. If so can we drop all 32 bit versions (In reply to Sravan Kumar Lakkimsetti from comment #15) > Can we start on this. If so can we drop all 32 bit versions Please go on. New Gerrit change created: https://git.eclipse.org/r/129105 New Gerrit change created: https://git.eclipse.org/r/129109 New Gerrit change created: https://git.eclipse.org/r/129110 New Gerrit change created: https://git.eclipse.org/r/129112 New Gerrit change created: https://git.eclipse.org/r/129113 New Gerrit change created: https://git.eclipse.org/r/129114 New Gerrit change created: https://git.eclipse.org/r/129115 New Gerrit change created: https://git.eclipse.org/r/129116 New Gerrit change created: https://git.eclipse.org/r/129117 New Gerrit change created: https://git.eclipse.org/r/129118 New Gerrit change created: https://git.eclipse.org/r/129119 The gerrit changes are not yet tested. Please wait before pusing the changes New Gerrit change created: https://git.eclipse.org/r/129226 Gerrit change https://git.eclipse.org/r/129105 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=7fc4b01e8620a7f4f093f0446c67b27363057ba1 Gerrit change https://git.eclipse.org/r/129110 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=8e31e92a85d1f91962e1bfe85bccf4252511f32d Gerrit change https://git.eclipse.org/r/129112 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=e2e6a2f3e41f3fc3df4ee7b22fb8f682cd4f2dd9 Gerrit change https://git.eclipse.org/r/129113 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6e6408baa0b45af4e16ac3bc5ee98256b5558a0b Gerrit change https://git.eclipse.org/r/129114 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=4fab52b8d32fa4cb3c83dd6e1237c592eed86bbb Gerrit change https://git.eclipse.org/r/129115 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=8e85123c2b8eb876bb2caff9684437ba84a0023f Gerrit change https://git.eclipse.org/r/129116 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ce03e74f703b644f0a3526f79dabbb51bea4dfd6 Gerrit change https://git.eclipse.org/r/129117 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=74b2c7dec679adecf7ceec14bb0ae28850737a29 Gerrit change https://git.eclipse.org/r/129118 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=6d15e724055fb261d84eaa9d618a4609f9ab2436 Gerrit change https://git.eclipse.org/r/129119 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=02bcc0e6c258e239c35f4b61aec1b95c9348b4ef Gerrit change https://git.eclipse.org/r/129226 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=37a7021bdb4c48acce9b44a5a832dd8d0ef0bb1a Gerrit change https://git.eclipse.org/r/129109 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=6980b06c3387c644dfc9f9015e85bb3c13569769 Merged to master now Windows tests did not get triggered. New Gerrit change created: https://git.eclipse.org/r/129513 Gerrit change https://git.eclipse.org/r/129513 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=d607478a1ea458800c630612439ac050cbc3816b (In reply to Sravan Kumar Lakkimsetti from comment #43) > Windows tests did not get triggered. We are rinnung windows tests on a 32 bit machine. So switching to another windows machine. Configuration: Windows 10 64 bit job: https://hudson.eclipse.org/releng/view/Automated%20tests/job/ep410I-unit-win32/ See Bug 539656. Removal of win32 x86 support breaks existing Tycho builds that reference SWT classes. The type org.eclipse.swt.graphics.Image cannot be resolved This occurs because existing builds retain a win32 x86 is-supported environment definition. Easily fixed by trimming the win32 x86 environment. But very obscure to debug what appears as a classpath failure within Tycho but not when running interactively. Needs at least better Tycho checking. New Gerrit change created: https://git.eclipse.org/r/130720 Gerrit change https://git.eclipse.org/r/130720 was merged to [master]. Commit: http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=f63ba7d58a118829df4d8b5df242a862d42941f5 New Gerrit change created: https://git.eclipse.org/r/132386 Gerrit change https://git.eclipse.org/r/132386 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b23625d4825e5c9c05f626b898d5b3c7455f0a11 Hello, just recognized that you dropped the 32 bit support without previous "deprecated" warning, at least for me. The percentage values, do they also cover products based on RCP or just the IDE? There was also a remark from Andrew Johnson which was not taken into further account. We are now also in the same situation, that we have to switch our delivered product to 64bit, without having really enough time to prepare customers, which are in several cases, still using 32bit VMs running our application. I don't want to argue to stay on 32bit, I'm just not happy about the way it was not communicated upfront. In my opinion, dropping support for a complete platform is a major change. But, it was handled like, "oh let's kick it out" from one day to the other. I would have expected that this might happen in the next big release after Photon, which would mean Summer next year. With communicating it right now. This would have given everyone enough time to handle it. What makes me really sad, is that I usually visit the EclipseCon because of that kind of information. And I heard at end of October nothing about that. There was a talk about Java and 32bit, there was a Eclipse talk about update strategy, but no one mentioned that Eclipse will drop 32bit between two minor releases. I hope that this is not part of the new strategy, if so, I would no one convince to use RCP as a platform for its own products. Please don't look only on IDE users, there are also a number of RCP users, which are not visible in your download statistics! (And yes, we can build everything on our own and ... but even for that you need time to plan it and to build up people with skills.) (In reply to Oliver Luecking from comment #52) > Hello, > just recognized that you dropped the 32 bit support without previous > "deprecated" warning, at least for me. > > The percentage values, do they also cover products based on RCP or just the > IDE? > There was also a remark from Andrew Johnson which was not taken into > further account. > > We are now also in the same situation, that we have to switch our delivered > product to 64bit, without having really enough time to prepare customers, > which are in several cases, still using 32bit VMs running our application. > > > I don't want to argue to stay on 32bit, I'm just not happy about the way it > was not communicated upfront. > > In my opinion, dropping support for a complete platform is a major change. > But, it was handled like, "oh let's kick it out" from one day to the other. That is not true. The best channel for such discussions is eclipse.org cross project mailing list. First iteration was for 4.9 - https://www.eclipse.org/lists/platform-swt-dev/msg08494.html. Second for 4.10 - https://www.eclipse.org/lists/cross-project-issues-dev/msg15898.html and it got zero interest from anyone. There were various tweets and other mails to project list about this happening. It was in the project plan https://wiki.eclipse.org/Platform/Plan/4.10 . What would have been the medium to use for widest distribution? > > I would have expected that this might happen in the next big release after > Photon, which would mean Summer next year. With communicating it right now. > This would have given everyone enough time to handle it. There are no longer "big releases" we do release every 3 months based on what was contributed in these 3 months. So June release might be bigger or way smaller than March release for example but from planning perspective they are absolutely equal. > > What makes me really sad, is that I usually visit the EclipseCon because of > that kind of information. And I heard at end of October nothing about that. > > There was a talk about Java and 32bit, there was a Eclipse talk about update > strategy, but no one mentioned that Eclipse will drop 32bit between two > minor releases. Releases are equal and there is no plan for major release for now. > > I hope that this is not part of the new strategy, if so, I would no one > convince to use RCP as a platform for its own products. As you can see from the mail threads - the question was bringed and deferred once allowing people to jump in to help. And with zero interest there was nothing to do. It is also critical to notice that we stopped building it but the 32 bit support is in the codebase so people can still build it, just the binary artifacts are not there. > > Please don't look only on IDE users, there are also a number of RCP users, > which are not visible in your download statistics! > > (And yes, we can build everything on our own and ... but even for that you > need time to plan it and to build up people with skills.) There is a major shift going on in the whole Java ecosystem (don't let me even start on javax.xml.bind, javax.annotation and Java 11 and time it costs still) and it imposes significantly higher velocity from everyone thus switch from passive to active informing has to happen. Removals,api changes and bigger changes are announced at cross-project-list giving months for people to reply or jump in. I can not think of better way to spread information as everyone has different "important" things and even conferences and etc. don't give the opportunity to speak to everyone personally for exactly the thing important to him. Sorry for the inconvenience this is causing you and hoping to see you more involved in the project. Just did https://twitter.com/akurtakov/status/1075678048341508097 to try to reach RCP authors - please spread and/or let us know how to reach more RCP authors so we keep you informed and involved in the discussions. (In reply to Oliver Luecking from comment #52) > still using 32bit VMs running our application. I'm naturally anti-change, but for me the overwhelming argument was that if a customer is determined to stick to old Java 32-bit VMs, they should also stick to the correspondingly old Eclipse. It is Oracle, not the EF, that is narrowing the potential compatibility bandwidth. Thanks everyone for feedback. Again, it is not about blaming someone, I really, really appreciate the work you are doing. It is also not about staying on 32bit. I'm happy to get rid of it as soon as possible. It was just about the point, that I had the feeling that something similar like dropping a complete platform, was something which probably was communicated upfront in the past and only implemented inside a major release. Please, even if Eclipse is not working anymore in yearly releases, please think about setting things to deprectaed upfront. IDE users might do not have the problem, but using RCP as a platform will break in worst case every three month the updateability. Not even because Eclipse kicks somehting out, but also other 3rd party things are not ready yet. It's not about "not doing something", it is just about please be careful and remind yourself about users of RCP. We are at the very far end of the queue. Java > Eclipse RCP > a bunch of other 3rd party things > own restrictions > own product I think the newsletter Alexander mentioned is a good point (did not know about that before). Even a small hints of bigger incompatible changes in Planet Eclipse would help already. @Ed Willink: As mentioned above, I have absolutely no trouble if there is enough time to solve such problems. Evolution is necessary and welcome! And in worst case we might stay for some time on the older platform. But in this case such a big change was a real surprise. I also expected that Eclipse will react to changes in Java. But the first time I recognized that 32bit was skipped, was when we downloaded 2018-12 and read the change log. And immediately we are kicked from further updates. I had the feeling, that in the past such a big loss of functionality might have been communicated upfront, even if they only affect 2% of IDE users plus unknown number of RCP users. Again, thank you very much. I hope you understand my concerns regarding planability and stability of the platform for RCP users. |