From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Question concerning the IDS2016 log Date: Tue, 13 Sep 2016 13:53:12 +0100 Message-ID: <1473771192.2757.136.camel@ipfire.org> In-Reply-To: <57D74754.2040401@dailydata.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5550859257921805102==" List-Id: --===============5550859257921805102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-12 at 19:24 -0500, R. W. Rodolico wrote: > On 09/12/2016 03:53 PM, Michael Tremer wrote: > >=20 > > Hi, > >=20 > > On Fri, 2016-09-09 at 22:54 -0500, R. W. Rodolico wrote: > > >=20 > > > 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 > >=20 > > 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. >=20 > 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 ev= en 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? > >=20 > > 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. > >=20 > > We will keep running the i586 version of IPFire 2 until we end > > support for IPFire 2 as a whole. > >=20 > > 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. > >=20 > 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 d= o. My advice would be: don't buy anything below 2G of memory, without a SSD or w= ith a too small CPU. > > > That is sad, because these are very stable systems and run nicely > > > with very little memory and extremely low power. > > >=20 > > > 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. > > >=20 > > > 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? > >=20 > > Fireinfo data shows the following (as of today): > >=20 > > * 13% of the systems known to fireinfo are running IPFire 2 x86_64=C2=A0 > > (http://fireinfo.ipfire.org/statistics/processors) > >=20 > > * 77% of all systems known to fireinfo would be able to run x86_64=C2=A0 > > (http://fireinfo.ipfire.org/statistics/processors/x86) > >=20 > > 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%. >=20 > 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 :) >=20 > >=20 > >=20 > > >=20 > > > But, I do see where ARM is not happening. > >=20 > > In fireinfo ARM basically does not exist. Sadly. > >=20 > > >=20 > > >=20 > > > Rod > > >=20 > > > On 09/08/2016 12:35 PM, Michael Tremer wrote: > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > On Thu, 2016-09-08 at 16:30 +0000, IT Superhack wrote: > > > > >=20 > > > > >=20 > > > > > Hello Michael, hello development-list, > > > > >=20 > > > > > I have a question concerning the IDS2016 (URL:=C2=A0 > > > > > http://wiki.ipfire.org/ids/2016 /log), where it says: > > > > > "Dropping i686 + armv5tel - No need for it any more" > > > >=20 > > > > 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. > > > >=20 > > > > But generally we didn't make as many decisions as we used to > > > > do since we have the monthly telephone conference. > > > >=20 > > > > >=20 > > > > >=20 > > > > > To me, it has not become fully clear if this means the=C2=A0 > > > > > 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. > > > >=20 > > > > So to give a little bit more detail: > > > >=20 > > > > The plan is to drop all 32 bit architectures as soon as > > > > possible. We do not see any point in supporting these any > > > > longer. > > > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > That is why we do not see any point whatsoever to continue=C2=A0 > > > > supporting these architectures. > > > >=20 > > > > We will keep armv7hl for now because there is a some hardware=C2=A0 > > > > around and our build system use it, but this will probably go > > > > away very soon when there is no usable hardware around soon. > > > >=20 > > > > >=20 > > > > >=20 > > > > > On the other hand, > 80% run an i686 system, and I guess it=C2=A0 > > > > > 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. > > > >=20 > > > > No, this will scrap support for i686 entirely. > > > >=20 > > > > >=20 > > > > >=20 > > > > > 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"? > > > >=20 > > > > We actually have done that in the past and we did not add any > > > > new hardware support in the last few years. > > > >=20 > > > > There is neither support nor any requests from the community > > > > for this. > > > >=20 > > > > 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. > > > >=20 > > > > >=20 > > > > >=20 > > > > > Sorry if there is a misunderstanding here - got way little > > > > > coffe today. ;-) > > > > >=20 > > > > > Best regards, Timmothy Wilson > > > >=20 > > > > Best, -Michael > > > >=20 >=20 --===============5550859257921805102== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlgxL2E1QUFvSkVJQjU4UDl2a0FrSGFEZ1AvMHk5aHRBUHNwR293Si9LbXRrTWFQeEIK bG9FNmMyRHZHZjJ2K3RQK3I5YUJDaUFFV1c5Wmh3UlZqYVZJSUNjM295MjltT05DKzRnaEFWRWhu elNtKytxOQpqUXdGNURWYzhaby9aeXFnb2Ywbkt4NEh6ZEtaeExpUFFuc0lzcGE4amxmYWc2M3dx RjIxOFVlRGt4NFRoaFJxClFTK3JGVmEzMGZBNkN2NVV6QWVJN2VqNHRXR2xmVW1UekRTdC9lTjBH OUxJc2Rxd3lsRnlwd2U4SENhRFB6THUKckhVcDQxN0xObVBZM0JHUjRFenBmZ2FaS0ZVYTdYZjYv enhCYUxWTVJOS3VlSW01MDNEckt0aEhLWTJsZk1lYgpBMzRVak8rQzVDRW9ubGVtU0l6akZOeFNv aW5GRlhnYzNteUNOTFAzZXRRMGxwQnRJOFN1YWU1WDFSRWJZVzJxCjUrd2xLSmZJTS93M1hkMzZm MnRnQmxqdG13VkczZnVMUmtwa2V0MTZJeXJWa3lmQUI0VWdvRnRDTEpDL1U2RXIKQkpFd2lTbDkw YmFlbEJaN3FkS0Q5YnREbWJDSnBPWkpoazNiblpaSWFQUnJsOCtFaUMvd29XeXhxdUd2TDZFUgpC YWd6TUFOTGpWNy9WaTg0WUV0TnhWaE9jMWZ0OUV5NWRxOWtDWWR6bXZsdzlWTnQvREI5TWFURlho NlRrSFJzCjd1WkNaWExUTzVqdWtNRUlxNUEyeFVhVnF5K3dDYWNQMTFxVWRHNHRRUVc1OFJXSDVZ Yi9rbG5lS3VibEh2azIKMkkwamFRdXVuemV3QkR6azhnbmlSdHlPZ2xmRjdOeVByYzlZTFJaK0NB clJpR21lRDg2RVhaVnc1OHdaajJiSQpaelMyQTNrOFJRR3A4aEdYdXVCKwo9eEZWTQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============5550859257921805102==--