public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
* Time is running out for 32-bit ARM
@ 2022-08-02 10:08 Peter Müller
  2022-08-06 12:24 ` Michael Tremer
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Müller @ 2022-08-02 10:08 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

Hello *,

in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
reasonably maintained on this architecture.

The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)

Thanks in advance for your reply, and best regards,
Peter Müller

[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/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-02 10:08 Time is running out for 32-bit ARM Peter Müller
@ 2022-08-06 12:24 ` Michael Tremer
  2022-08-06 12:40   ` Adolf Belka
  0 siblings, 1 reply; 8+ messages in thread
From: Michael Tremer @ 2022-08-06 12:24 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
> reasonably maintained on this architecture.
> 
> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
> 
> Thanks in advance for your reply, and best regards,
> Peter Müller
> 
> [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/


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-06 12:24 ` Michael Tremer
@ 2022-08-06 12:40   ` Adolf Belka
  2022-08-06 15:31     ` Michael Tremer
  0 siblings, 1 reply; 8+ messages in thread
From: Adolf Belka @ 2022-08-06 12:40 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 3744 bytes --]

Hi All,

Michael's suggested approach sounds fine to me. However, like Peter, I 
don'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 
that will also provide input.

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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
>>
>> Hello *,
>>
>> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
>> reasonably maintained on this architecture.
>>
>> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
>>
>> Thanks in advance for your reply, and best regards,
>> Peter Müller
>>
>> [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/

-- 
Sent from my laptop


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-06 12:40   ` Adolf Belka
@ 2022-08-06 15:31     ` Michael Tremer
  2022-08-14 16:29       ` Michael Tremer
  2022-08-14 16:30       ` Michael Tremer
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Tremer @ 2022-08-06 15:31 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]

Hello,

> On 6 Aug 2022, at 13:40, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> Michael's suggested approach sounds fine to me. However, like Peter, I don'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 that 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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
>>> 
>>> Hello *,
>>> 
>>> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
>>> reasonably maintained on this architecture.
>>> 
>>> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
>>> 
>>> Thanks in advance for your reply, and best regards,
>>> Peter Müller
>>> 
>>> [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/
> 
> -- 
> Sent from my laptop
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-06 15:31     ` Michael Tremer
@ 2022-08-14 16:29       ` Michael Tremer
  2022-08-14 17:21         ` Peter Müller
  2022-08-14 16:30       ` Michael Tremer
  1 sibling, 1 reply; 8+ messages in thread
From: Michael Tremer @ 2022-08-14 16:29 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 5121 bytes --]

Hello everyone,

So since we had a good week of silence on this, I think it is time to come to a decision.

I had a conversation with Arne today to check on the last few things I needed 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.

That date has been chosen as a compromise between shutting it down sooner rather than later, and giving people enough time to migrate away. It is a little bit over 6 months which should be enough time to find some new hardware for the people affected.

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 six months.

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 this architecture.

Best,
-Michael

> On 6 Aug 2022, at 16:31, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hello,
> 
>> On 6 Aug 2022, at 13:40, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>> 
>> Hi All,
>> 
>> Michael's suggested approach sounds fine to me. However, like Peter, I don'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 that 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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
>>>> 
>>>> Hello *,
>>>> 
>>>> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
>>>> reasonably maintained on this architecture.
>>>> 
>>>> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
>>>> 
>>>> Thanks in advance for your reply, and best regards,
>>>> Peter Müller
>>>> 
>>>> [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/
>> 
>> -- 
>> Sent from my laptop
>> 
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-06 15:31     ` Michael Tremer
  2022-08-14 16:29       ` Michael Tremer
@ 2022-08-14 16:30       ` Michael Tremer
  1 sibling, 0 replies; 8+ messages in thread
From: Michael Tremer @ 2022-08-14 16:30 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-14 16:29       ` Michael Tremer
@ 2022-08-14 17:21         ` Peter Müller
  2022-08-14 17:23           ` Michael Tremer
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Müller @ 2022-08-14 17:21 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 5703 bytes --]

Hello Michael,

thanks for your mail.

> Hello everyone,
> 
> So since we had a good week of silence on this, I think it is time to come to a decision.
> 
> I had a conversation with Arne today to check on the last few things I needed 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.
> 
> That date has been chosen as a compromise between shutting it down sooner rather than later, and giving people enough time to migrate away. It is a little bit over 6 months which should be enough time to find some new hardware for the people affected.

Yes, that is a sane decision in my opinion as well.

> 
> 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 six months.
> 
> 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 this architecture.

Thank you.

I will then update the relevant parts of the wiki to make clear that 32-bit ARM 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 Update 171
is enough?

Thanks, and best regards,
Peter Müller

> 
> Best,
> -Michael
> 
>> On 6 Aug 2022, at 16:31, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>
>> Hello,
>>
>>> On 6 Aug 2022, at 13:40, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> Michael's suggested approach sounds fine to me. However, like Peter, I don'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 that 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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
>>>>>
>>>>> Hello *,
>>>>>
>>>>> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
>>>>> reasonably maintained on this architecture.
>>>>>
>>>>> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
>>>>>
>>>>> Thanks in advance for your reply, and best regards,
>>>>> Peter Müller
>>>>>
>>>>> [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/
>>>
>>> -- 
>>> Sent from my laptop
>>>
>>
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Time is running out for 32-bit ARM
  2022-08-14 17:21         ` Peter Müller
@ 2022-08-14 17:23           ` Michael Tremer
  0 siblings, 0 replies; 8+ messages in thread
From: Michael Tremer @ 2022-08-14 17:23 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 6191 bytes --]

Hello,

> On 14 Aug 2022, at 18:21, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> thanks for your mail.
> 
>> Hello everyone,
>> 
>> So since we had a good week of silence on this, I think it is time to come to a decision.
>> 
>> I had a conversation with Arne today to check on the last few things I needed 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.
>> 
>> That date has been chosen as a compromise between shutting it down sooner rather than later, and giving people enough time to migrate away. It is a little bit over 6 months which should be enough time to find some new hardware for the people affected.
> 
> Yes, that is a sane decision in my opinion as well.
> 
>> 
>> 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 six months.
>> 
>> 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 this architecture.
> 
> Thank you.
> 
> I will then update the relevant parts of the wiki to make clear that 32-bit ARM is
> discontinued, people should not buy new devices of this kind, etc. pp.

Thank you.

> 
> 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 Update 171
> is enough?

Yes. Would you like to draft one? We can talk about what we would like to say in it. I don’t think just half a page of what we are doing is good enough. We should reflect slightly on how the journey was.

> Thanks, and best regards,
> Peter Müller
> 
>> 
>> Best,
>> -Michael
>> 
>>> On 6 Aug 2022, at 16:31, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>>> 
>>> Hello,
>>> 
>>>> On 6 Aug 2022, at 13:40, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Michael's suggested approach sounds fine to me. However, like Peter, I don'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 that 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 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, this has surpassed the threshold where there is no growing or steady user base 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 it will 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 of 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 don’t think that we should make life too much more complicated for 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 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üller <peter.mueller(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hello *,
>>>>>> 
>>>>>> in January [1], we already discussed the situation of 32-bit ARM, and settled 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 Intel 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 distribution
>>>>>> reasonably maintained on this architecture.
>>>>>> 
>>>>>> The other night, we have therefore agreed on putting an end to IPFire support 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 installations 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 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. :-)
>>>>>> 
>>>>>> Thanks in advance for your reply, and best regards,
>>>>>> Peter Müller
>>>>>> 
>>>>>> [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/
>>>> 
>>>> -- 
>>>> Sent from my laptop
>>>> 
>>> 
>> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-08-14 17:23 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-02 10:08 Time is running out for 32-bit ARM Peter Müller
2022-08-06 12:24 ` Michael Tremer
2022-08-06 12:40   ` Adolf Belka
2022-08-06 15:31     ` Michael Tremer
2022-08-14 16:29       ` Michael Tremer
2022-08-14 17:21         ` Peter Müller
2022-08-14 17:23           ` Michael Tremer
2022-08-14 16:30       ` Michael Tremer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox