Question concerning the IDS2016 log

R. W. Rodolico rodo at dailydata.net
Tue Sep 13 02:24:52 CEST 2016


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


On 09/12/2016 03:53 PM, Michael Tremer wrote:
> Hi,
> 
> On Fri, 2016-09-09 at 22:54 -0500, R. W. Rodolico wrote:
>> 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
> 
> The form factor of that hardware is nice, but it is really
> outdated. You can get something way more powerful for about the
> same money I think.

I just try to build firewalls that last a really long time and use
minimum power. However, the same company has a different model (6501
series) that has an atom in it instead of a geode, so I'll just make
sure to use those in the future. Slightly higher power consumption (8
watts vs 6 for the 5501), but still not bad.

> 
>> I'm assuming they will not be able to be upgraded after a certain
>> point?
> 
> I am not sure if this was clear or not, but this change will only
> affect IPFire 3. So with that there will be no i686 version.
> 
> We will keep running the i586 version of IPFire 2 until we end
> support for IPFire 2 as a whole.
> 
> But we think that the hardware (mainly memory) requirements for
> IPFire 3 will exceed this hardware any ways and as there are many
> alternatives available you should not buy anything too old any
> more. Anything that is about 8 years or newer will probably support
> 64 bit.
> 
Haven't sold many firewalls recently, so I can live with the
restriction on IPFire 3. Yes, you guys are putting tons of work into
it, and I can see where it may need more resources on a box running
it. I run IPFire 2 on 512M of RAM, and have never run out of memory
(but, came within 5% one time during an update). All the things you've
been talking about with 3 will require more resources.


>> 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?
> 
> Fireinfo data shows the following (as of today):
> 
> * 13% of the systems known to fireinfo are running IPFire 2 x86_64 
> (http://fireinfo.ipfire.org/statistics/processors)
> 
> * 77% of all systems known to fireinfo would be able to run x86_64 
> (http://fireinfo.ipfire.org/statistics/processors/x86)
> 
> So that is a huge majority. I assume that many of the VMs are just
> running as 32 bit and probably would support 64 bit, too. So that
> number could be close to 90%.

I'm guilty of that; I have some vm's running which are quite possibly
32bit, but they are on 64 bit machines and could likely be upgraded
easily. Just add RAM :)

> 
>> But, I do see where ARM is not happening.
> 
> In fireinfo ARM basically does not exist. Sadly.
> 
>> 
>> 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)

iEYEARECAAYFAlfXR1QACgkQuVY3UpYMlTRNDgCfUVQcUfpewtUwW4TweXI4M+7O
AogAn2CR9thN49Dnv+tqasB+itad8Pg9
=txHR
-----END PGP SIGNATURE-----


More information about the Development mailing list