public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
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-----

  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