From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Time is running out for 32-bit ARM Date: Sun, 14 Aug 2022 17:21:20 +0000 Message-ID: <5fa9edd9-07de-9d4f-044e-cc78b6bcf10b@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4599171755366178407==" List-Id: --===============4599171755366178407== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, thanks for your mail. > Hello everyone, >=20 > So since we had a good week of silence on this, I think it is time to come = to a decision. >=20 > I had a conversation with Arne today to check on the last few things I need= ed to know and together (and based on opinions voiced by others and the facts= ) we have made the decision to retire support for armv6l by Feb 28 2023. >=20 > That date has been chosen as a compromise between shutting it down sooner r= ather than later, and giving people enough time to migrate away. It is a litt= le bit over 6 months which should be enough time to find some new hardware fo= r the people affected. Yes, that is a sane decision in my opinion as well. >=20 > There is now officially nobody in the group of developers who wants to keep= this architecture alive, and I think it is the best way to give it another s= ix months. >=20 > I will submit a patch to show a warning and in early February will submit a= patch that removes any extra code or quirks that we have implemented for thi= s architecture. Thank you. I will then update the relevant parts of the wiki to make clear that 32-bit A= RM is discontinued, people should not buy new devices of this kind, etc. pp. Should we publish a short blog post on this? Or do you think (given the small= user base affected), mentioning the deprecation in the release notes of Core Updat= e 171 is enough? Thanks, and best regards, Peter M=C3=BCller >=20 > Best, > -Michael >=20 >> On 6 Aug 2022, at 16:31, Michael Tremer wrot= e: >> >> Hello, >> >>> On 6 Aug 2022, at 13:40, Adolf Belka wrote: >>> >>> Hi All, >>> >>> Michael's suggested approach sounds fine to me. However, like Peter, I do= n't use any arm machines for IPFire so I don't have any impact personally. >>> >>> Hopefully there will be some arm users that are on the dev mailing list t= hat will also provide input. >> >> That would be great indeed. If not, I will also take that as answer. >> >>> >>> Regards, >>> Adolf. >>> >>> >>> On 06/08/2022 14:24, Michael Tremer wrote: >>>> 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= than a year >>>> * We keep hosting the packages for another three months and will remove = them 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 i= s 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= , this has surpassed the threshold where there is no growing or steady user b= ase any more. >>>> >>>> Having said that, aarch64 (as of today) only has 1.29% of our users. Not= particularly a lot, but it has been steadily growing. Fingers crossed that i= t will gain more momentum in the future. >>>> >>>> Why would we not discontinue this now? I personally feel that I would li= ke to give people decent time to migrate away from this. Right now, we have l= ots of supply issues, it is already mid-August, which would result in about t= hree months until EOL. Not that this would offend a large number of users, bu= t I don=E2=80=99t think that we should make life too much more complicated fo= r anyone than it has to be. >>>> >>>> We still have a running distribution that does not have any significant = problems on armv6l compared to the other architectures. It costs us build tim= es - yes. It might cost us some extra development time - yes. But this is wha= t 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 = wrote: >>>>> >>>>> Hello *, >>>>> >>>>> in January [1], we already discussed the situation of 32-bit ARM, and s= ettled on >>>>> demoting this architecture as "legacy" on [2], and advising people from= buying new >>>>> 32-bit ARM hardware in the wiki. >>>>> >>>>> To some extends, this architecture shares a similar fate than 32-bit In= tel did: >>>>> Security features are not backported to it, maintenance requires a lot = of effort >>>>> due to missing upstream support, hardware base is diminishing, and its = IPFire >>>>> userbase does not justify the resources required for keeping the distri= bution >>>>> reasonably maintained on this architecture. >>>>> >>>>> The other night, we have therefore agreed on putting an end to IPFire s= upport for >>>>> 32-bit ARM, and take the question of the anticipated timeframe to this = mailing list. >>>>> [3] >>>>> >>>>> At the time of writing, Fireinfo reports 0.94% of all IPFire installati= ons to run >>>>> on supported 32-bit ARM devices, to give you a figure. [4] >>>>> >>>>> Personally, since these devices are unlikely to run in enterprises or o= ther 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 installatio= ns, my >>>>> opinion is biased - let's hear yours. :-) >>>>> >>>>> Thanks in advance for your reply, and best regards, >>>>> Peter M=C3=BCller >>>>> >>>>> [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/ >>> >>> --=20 >>> Sent from my laptop >>> >> >=20 --===============4599171755366178407==--