Question concerning the IDS2016 log

IT Superhack itsuperhack at web.de
Sun Sep 11 11:48:00 CEST 2016


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ipfire.org/pipermail/development/attachments/20160911/08e8fdfb/attachment.sig>


More information about the Development mailing list