From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Question concerning the IDS2016 log
Date: Mon, 12 Sep 2016 21:53:43 +0100 [thread overview]
Message-ID: <1473713623.2757.109.camel@ipfire.org> (raw)
In-Reply-To: <57D38407.3030801@dailydata.net>
[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]
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'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.
> 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%.
> 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
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-09-12 20:53 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 [this message]
2016-09-13 0:24 ` R. W. Rodolico
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=1473713623.2757.109.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--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