Re: Question concerning the IDS2016 log

["R. W. Rodolico" <rodo@dailydata.net>]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, I have 10+ systems running on Soekris machines, i586 32 bit
AMD Geode's. See http://soekris.com/products/net5501.html. These are
not end of life; they are currently being marketed for vpn
firewall/routers. I have some that have been running

I'm assuming they will not be able to be upgraded after a certain point?

That is sad, because these are very stable systems and run nicely with
very little memory and extremely low power.

One of the offices I use it at has 50+ employees, 40+ Mbit data line,
and some firewall rules built in, along with a site-to-site VPN and a
couple or Road Warriors.

All of these systems have pakinfo running on them, so you should see
them in the database. Fireinfo appears to show only 13% of the
firewalls out there are 64 bit? Am I reading that wrong?

But, I do see where ARM is not happening.

Rod

On 09/08/2016 12:35 PM, Michael Tremer wrote:
> 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
> 

- -- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfThAYACgkQuVY3UpYMlTTYjgCeKDNRejuYH5Xl7q7YxKoXtXJ8
qPMAmQGnbWb/tUIz5kK/OPay5OPN6heP
=upFr
-----END PGP SIGNATURE-----