public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: IT Superhack <itsuperhack@web.de>
To: development@lists.ipfire.org
Subject: Re: Question concerning the IDS2016 log
Date: Sun, 11 Sep 2016 09:48:00 +0000	[thread overview]
Message-ID: <69678539-d99f-ff78-db1b-c170bfd26c85@web.de> (raw)
In-Reply-To: <1473356159.2757.77.camel@ipfire.org>

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

Hello,

Michael Tremer:
> 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.
That's okay. The logs of your telephone conferences are mostly very useful. :-)
> 
>> 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.
In my point of view, that's really sad. ARM could be a great thing if the vendors
would provide the source codes (which most of them don't) and if the boards would
last for some time.

Personally, I am content with the ARM architecture for firewall purposes since
it is more secure. For example, there is no "Management Engine", which we know from Intel CPUs
(https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Security).

Second, it is very hard to find a usable hardware which is only consummating ~ 3
Watts when idle.
> 
> 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.
Hm, I see. Hope devices like Banana Pi and Wandboard will last some time...
> 
>> 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.
Well, as Rod wrote in his mail, there might be some networks which consist of
"legacy" systems. Here, it might be useful to post a message on the planet a month
or so before discontinue support so they can upgrade.
> 
>> Sorry if there is a misunderstanding here - got way little coffe today. ;-)
>>
>> Best regards,
>> Timmothy Wilson
> 
> Best,
> -Michael
> 
Best regards,
Timmothy Wilson



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

  parent reply	other threads:[~2016-09-11  9:48 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
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 [this message]
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=69678539-d99f-ff78-db1b-c170bfd26c85@web.de \
    --to=itsuperhack@web.de \
    --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