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 --]
next prev 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