From: "R. W. Rodolico" <rodo@dailydata.net>
To: development@lists.ipfire.org
Subject: Re: Question concerning the IDS2016 log
Date: Mon, 12 Sep 2016 19:24:52 -0500 [thread overview]
Message-ID: <57D74754.2040401@dailydata.net> (raw)
In-Reply-To: <1473713623.2757.109.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6598 bytes --]
-----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-----
next prev parent reply other threads:[~2016-09-13 0:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-08 16:30 IT Superhack
2016-09-08 17:35 ` Michael Tremer
2016-09-10 3:54 ` R. W. Rodolico
2016-09-12 20:53 ` Michael Tremer
2016-09-13 0:24 ` R. W. Rodolico [this message]
2016-09-13 12:53 ` Michael Tremer
2016-09-11 9:48 ` IT Superhack
2016-09-12 21:04 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57D74754.2040401@dailydata.net \
--to=rodo@dailydata.net \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox