From mboxrd@z Thu Jan 1 00:00:00 1970 From: "R. W. Rodolico" To: development@lists.ipfire.org Subject: Re: Question concerning the IDS2016 log Date: Mon, 12 Sep 2016 19:24:52 -0500 Message-ID: <57D74754.2040401@dailydata.net> In-Reply-To: <1473713623.2757.109.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4011110212203753728==" List-Id: --===============4011110212203753728== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit -----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----- --===============4011110212203753728==--