Re: Question concerning the IDS2016 log

[Michael Tremer <michael.tremer@ipfire.org>]

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

On Mon, 2016-09-12 at 19:24 -0500, R. W. Rodolico wrote:
> 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.

Modern systems don't use more. Probably even less.

But I think this board is terribly overpriced. It is nice. But I would not even
buy it for a quarter of that price shown on their website.

This is a different topic though...

> > > 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.

It is not strictly needed. I think that IPFire 3 still has a relatively small
footprint. But if you look at how cheap memory is there is no reason to save on
that. So everyone is "wasting" a little bit. Kernel, user-space, ... and that
just adds up. Nobody is restricting themselves any more.

And of course a modern IPFire box has to do way more things than it used to do.

My advice would be: don't buy anything below 2G of memory, without a SSD or with
a too small CPU.

> > > 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
> > > > 
> 

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