From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: On demoting i586 to "legacy" status Date: Thu, 06 Aug 2020 15:26:34 +0100 Message-ID: <6007DE2A-8CFD-41F9-8373-84C88917EB35@ipfire.org> In-Reply-To: <20200806142145.GC13914@tarvainen.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1557579701005034430==" List-Id: --===============1557579701005034430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, > On 6 Aug 2020, at 15:21, Tapani Tarvainen wro= te: >=20 > I just realized *all* of the IPFire boxes in my care are running > on 32-bit hardware. >=20 > I do hope support won't be dropped in the next few months. >=20 > 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." >=20 > https://itsfoss.com/32-bit-os-list/ >=20 > Even in the developed world, replacing hardware isn't always easy. I understand your concern. > So, please don't rush it. This isn=E2=80=99t necessarily our decision. As stated before, kernel support for 32 bits is bad. None of the big commerci= al 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 th= ere for them. Hence we have to fix all the bugs on our own which we simply can=E2=80=99t 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 u= sers. Best, -Michael >=20 > Tapani >=20 > On Wed, Aug 05, 2020 at 01:08:08PM +0100, Michael Tremer (michael.tremer(a)= ipfire.org) wrote: >>=20 >> Hello, >>=20 >> This is me catching up with my very very long TODO list (i.e. book)=E2=80= =A6 >>=20 >> We have talked about making it clearer that 32 bit on x86 is no longer a g= ood choice for users at the telephone conference in May: >>=20 >> https://wiki.ipfire.org/devel/telco/2020-05-04 >>=20 >> I took on the job to make this clearer on the website in the download sect= ion which I rolled out yesterday: >>=20 >> https://www.ipfire.org/download >>=20 >> 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. >>=20 >> However, this splits the offered architectures into two sections now: >>=20 >> * Primary Architectures (x86_64, arm) >> * Secondary Architectures (i586, aarch64) >>=20 >> i586 will be a primary architecture for all releases that did not have x86= _64. >>=20 >> Aarch64 is a secondary architecture because Arne wanted it marked as =E2= =80=9Cexperimental=E2=80=9D. 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 inf= rastructure. >>=20 >> I have split the two sections by the =E2=80=9CCloud advert=E2=80=9D in the= middle which promotes Cloud over the secondary arches and makes it clear tha= t secondary really means secondary because users will have to scroll a lot to= find i586 now. That does it for me now. >>=20 >> I would prefer to keep images on the download page (even for aarch64), bec= ause if we do not make them available like this, what is the point to build t= hem in the first place? >>=20 >> The next steps are adding a warning to the web UI that people who are runn= ing 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 s= tands at 26.75% in fire info, which means we have to convince 20% of our user= s to change. Possible, but not within the next few months. A blog article wil= l hopefully help. >>=20 >> Best, >> -Michael --===============1557579701005034430==--