public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: On demoting i586 to "legacy" status
Date: Thu, 06 Aug 2020 15:26:34 +0100	[thread overview]
Message-ID: <6007DE2A-8CFD-41F9-8373-84C88917EB35@ipfire.org> (raw)
In-Reply-To: <20200806142145.GC13914@tarvainen.info>

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

Hey,

> On 6 Aug 2020, at 15:21, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> I just realized *all* of the IPFire boxes in my care are running
> on 32-bit hardware.
> 
> I do hope support won't be dropped in the next few months.
> 
> Quote: "[...] in the developed world we assume that we can replace
> things; in some parts of the developing world older IA-32 systems are
> still the norm, with 64-bit being rare."
> 
> https://itsfoss.com/32-bit-os-list/
> 
> Even in the developed world, replacing hardware isn't always easy.

I understand your concern.

> So, please don't rush it.

This isn’t necessarily our decision.

As stated before, kernel support for 32 bits is bad. None of the big commercial Linux distributions is releasing a 32 bit version any more. RHEL, Ubuntu, CentOS, Arch do not exist for i686 AFAIK. There is simply no money to earn there for them.

Hence we have to fix all the bugs on our own which we simply can’t do.

We knew that this has been coming for a while now. See here:

  https://blog.ipfire.org/post/32-bit-is-dead-long-live-32-bit

We are trying our best here, but if usage of that architecture drops below 5% or so we can rather invest our time into something else that benefits more users.

Best,
-Michael

> 
> Tapani
> 
> On Wed, Aug 05, 2020 at 01:08:08PM +0100, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
>> 
>> Hello,
>> 
>> This is me catching up with my very very long TODO list (i.e. book)…
>> 
>> We have talked about making it clearer that 32 bit on x86 is no longer a good choice for users at the telephone conference in May:
>> 
>>  https://wiki.ipfire.org/devel/telco/2020-05-04
>> 
>> I took on the job to make this clearer on the website in the download section which I rolled out yesterday:
>> 
>>  https://www.ipfire.org/download
>> 
>> I am not happy with the whole download section at all, but this is what we have for now. New design is in the works.
>> 
>> However, this splits the offered architectures into two sections now:
>> 
>> * Primary Architectures (x86_64, arm)
>> * Secondary Architectures (i586, aarch64)
>> 
>> i586 will be a primary architecture for all releases that did not have x86_64.
>> 
>> Aarch64 is a secondary architecture because Arne wanted it marked as “experimental”. We do not exactly know how well it runs on some boards, although we have been using it for quite a long time in the build infrastructure.
>> 
>> I have split the two sections by the “Cloud advert” in the middle which promotes Cloud over the secondary arches and makes it clear that secondary really means secondary because users will have to scroll a lot to find i586 now. That does it for me now.
>> 
>> I would prefer to keep images on the download page (even for aarch64), because if we do not make them available like this, what is the point to build them in the first place?
>> 
>> The next steps are adding a warning to the web UI that people who are running on i586 are running a legacy system now. We will support it, but we will advice against using it until we have only a few users left. Currently i686 stands at 26.75% in fire info, which means we have to convince 20% of our users to change. Possible, but not within the next few months. A blog article will hopefully help.
>> 
>> Best,
>> -Michael


  reply	other threads:[~2020-08-06 14:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 12:08 Michael Tremer
2020-08-05 12:24 ` Michael Tremer
2020-08-06 14:21 ` Tapani Tarvainen
2020-08-06 14:26   ` Michael Tremer [this message]
2020-08-06 14:55     ` Tapani Tarvainen
2020-08-06 15:50       ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6007DE2A-8CFD-41F9-8373-84C88917EB35@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox