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