From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Time is running out for 32-bit ARM Date: Sat, 06 Aug 2022 13:24:01 +0100 Message-ID: In-Reply-To: <540965b3-4417-8fb1-7802-a36f5fc63b93@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0452090223535594285==" List-Id: --===============0452090223535594285== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all, Thank you for picking this up on the list. I would like to make the following proposal: * We discontinue building for armv6l on May 31st 2023 - in a little less th= an a year * We keep hosting the packages for another three months and will remove the= m from the servers after that This is based on the following: * As of today, have 0.98% of our user base on armv6l * This used to be 1.69% on Jan 1st, 2021 and 1.67% on Jan 1st, 2022. There is definitely a decline in the usage of that architecture and it is of = course incredibly small anyways. With all the extra work and workarounds that= we have in the code base here, the days and weeks that is going into it, thi= s has surpassed the threshold where there is no growing or steady user base a= ny more. Having said that, aarch64 (as of today) only has 1.29% of our users. Not part= icularly a lot, but it has been steadily growing. Fingers crossed that it wil= l gain more momentum in the future. Why would we not discontinue this now? I personally feel that I would like to= give people decent time to migrate away from this. Right now, we have lots o= f supply issues, it is already mid-August, which would result in about three = months until EOL. Not that this would offend a large number of users, but I d= on=E2=80=99t think that we should make life too much more complicated for any= one than it has to be. We still have a running distribution that does not have any significant probl= ems on armv6l compared to the other architectures. It costs us build times - = yes. It might cost us some extra development time - yes. But this is what we = have signed up for when we adopted this architecture. So we have to bear some= responsibility. -Michael > On 2 Aug 2022, at 11:08, Peter M=C3=BCller wro= te: >=20 > Hello *, >=20 > in January [1], we already discussed the situation of 32-bit ARM, and settl= ed on > demoting this architecture as "legacy" on [2], and advising people from buy= ing new > 32-bit ARM hardware in the wiki. >=20 > To some extends, this architecture shares a similar fate than 32-bit Intel = did: > Security features are not backported to it, maintenance requires a lot of e= ffort > due to missing upstream support, hardware base is diminishing, and its IPFi= re > userbase does not justify the resources required for keeping the distributi= on > reasonably maintained on this architecture. >=20 > The other night, we have therefore agreed on putting an end to IPFire suppo= rt for > 32-bit ARM, and take the question of the anticipated timeframe to this mail= ing list. > [3] >=20 > At the time of writing, Fireinfo reports 0.94% of all IPFire installations = to run > on supported 32-bit ARM devices, to give you a figure. [4] >=20 > Personally, since these devices are unlikely to run in enterprises or other= critical > environments, I would be fine with announcing EOL for 32-bit ARM at the end= of > this year. However, as I am not running any affected IPFire installations, = my > opinion is biased - let's hear yours. :-) >=20 > Thanks in advance for your reply, and best regards, > Peter M=C3=BCller >=20 > [1] https://wiki.ipfire.org/devel/telco/2022-01-03 > [2] https://www.ipfire.org/download > [3] https://wiki.ipfire.org/devel/telco/2022-08-01 > [4] https://fireinfo.ipfire.org/ --===============0452090223535594285==--