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: Question concerning the IDS2016 log
Date: Thu, 08 Sep 2016 18:35:59 +0100	[thread overview]
Message-ID: <1473356159.2757.77.camel@ipfire.org> (raw)
In-Reply-To: <b1bd68ef-0e47-33fa-08ca-c334be8d2085@web.de>

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

Hi,

On Thu, 2016-09-08 at 16:30 +0000, IT Superhack wrote:
> Hello Michael,
> hello development-list,
> 
> I have a question concerning the IDS2016 (URL: http://wiki.ipfire.org/ids/2016
> /log),
> where it says: "Dropping i686 + armv5tel - No need for it any more"

Yeah, we didn't really log everything what we talked about. There was a little
bit more than that and there is probably a little bit more detail to all of it
than that.

But generally we didn't make as many decisions as we used to do since we have
the monthly telephone conference.

> To me, it has not become fully clear if this means the architecture or the
> whole
> release format. For example, nearly nobody (Fireinfo says: 0,07%) is running
> an IPFire system with the armv5tel architecture - these are afaik mostly old
> systems like the Raspberry Pi which are certainly not suitable for a firewall
> purpose.

So to give a little bit more detail:

The plan is to drop all 32 bit architectures as soon as possible. We do not see
any point in supporting these any longer.

That starts with ARM where we never really got a number of users that is high
enough to justify all the effort that is going into development of this.

And secondly x86: All hardware that is bought today or in the last ~5 years will
support 64 bit. If it doesn't and if someone bought an other ALIX device that is
just bad luck. These are too slow to run an IPFire system decently any ways and
there is better alternatives on the market.

That is why we do not see any point whatsoever to continue supporting these
architectures.

We will keep armv7hl for now because there is a some hardware around and our
build system use it, but this will probably go away very soon when there is no
usable hardware around soon.

> On the other hand, > 80% run an i686 system, and I guess it wouldn't make
> sense to make these installations unusable because of EOL. But maybe
> "dropping"
> means that you will remove some specific patches for i686, so these will
> run with i586 afterwards.

No, this will scrap support for i686 entirely.

> Within the ARM stuff, the situation is not that clear for me. Are you panning
> to remove the ARM support at all? Or are you going to remove ARMv5 devices
> from
> the "supported ARM devices list"?

We actually have done that in the past and we did not add any new hardware
support in the last few years.

There is neither support nor any requests from the community for this.

Feel free to leave your comments on this. Would be happy to hear if someone can
come up with at least one argument to continue 32 bit support. We couldn't find
a single one.

> Sorry if there is a misunderstanding here - got way little coffe today. ;-)
> 
> Best regards,
> Timmothy Wilson

Best,
-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-09-08 17:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-08 16:30 IT Superhack
2016-09-08 17:35 ` Michael Tremer [this message]
2016-09-10  3:54   ` R. W. Rodolico
2016-09-12 20:53     ` Michael Tremer
2016-09-13  0:24       ` R. W. Rodolico
2016-09-13 12:53         ` Michael Tremer
2016-09-11  9:48   ` IT Superhack
2016-09-12 21:04     ` 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=1473356159.2757.77.camel@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