Question concerning the IDS2016 log

Question concerning the IDS2016 log

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

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"

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.

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.

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"?

Sorry if there is a misunderstanding here - got way little coffe today. ;-)

Best regards,
Timmothy Wilson


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Question concerning the IDS2016 log

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

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 --]

Re: Question concerning the IDS2016 log

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 4127 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

I'm assuming they will not be able to be upgraded after a certain point?

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?

But, I do see where ARM is not happening.

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)

iEYEARECAAYFAlfThAYACgkQuVY3UpYMlTTYjgCeKDNRejuYH5Xl7q7YxKoXtXJ8
qPMAmQGnbWb/tUIz5kK/OPay5OPN6heP
=upFr
-----END PGP SIGNATURE-----

Re: Question concerning the IDS2016 log

[Michael Tremer]

[-- 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 --]

Re: Question concerning the IDS2016 log

[R. W. Rodolico]

[-- 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-----

Re: Question concerning the IDS2016 log

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7823 bytes --]

On Mon, 2016-09-12 at 19:24 -0500, R. W. Rodolico wrote:
> 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.

Modern systems don't use more. Probably even less.

But I think this board is terribly overpriced. It is nice. But I would not even
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?
> > 
> > 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.

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 do.

My advice would be: don't buy anything below 2G of memory, without a SSD or with
a too small CPU.

> > > 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
> > > > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Question concerning the IDS2016 log

[IT Superhack]

[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]

Hello,

Michael Tremer:
> 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.
That's okay. The logs of your telephone conferences are mostly very useful. :-)
> 
>> 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.
In my point of view, that's really sad. ARM could be a great thing if the vendors
would provide the source codes (which most of them don't) and if the boards would
last for some time.

Personally, I am content with the ARM architecture for firewall purposes since
it is more secure. For example, there is no "Management Engine", which we know from Intel CPUs
(https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Security).

Second, it is very hard to find a usable hardware which is only consummating ~ 3
Watts when idle.
> 
> 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.
Hm, I see. Hope devices like Banana Pi and Wandboard will last some time...
> 
>> 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.
Well, as Rod wrote in his mail, there might be some networks which consist of
"legacy" systems. Here, it might be useful to post a message on the planet a month
or so before discontinue support so they can upgrade.
> 
>> Sorry if there is a misunderstanding here - got way little coffe today. ;-)
>>
>> Best regards,
>> Timmothy Wilson
> 
> Best,
> -Michael
> 
Best regards,
Timmothy Wilson



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Question concerning the IDS2016 log

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]

Hi,

On Sun, 2016-09-11 at 09:48 +0000, IT Superhack wrote:
> Hello,
> 
> Michael Tremer:
> > 
> > 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.
> That's okay. The logs of your telephone conferences are mostly very useful. :-
> )
> > 
> > 
> > > 
> > > 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.
> In my point of view, that's really sad. ARM could be a great thing if the
> vendors
> would provide the source codes (which most of them don't) and if the boards
> would
> last for some time.
> 
> Personally, I am content with the ARM architecture for firewall purposes since
> it is more secure. For example, there is no "Management Engine", which we know
> from Intel CPUs
> (https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Security).
> 
> Second, it is very hard to find a usable hardware which is only consummating ~
> 3
> Watts when idle.

According to the numbers there would be no reason to support ARM.

But I generally agree with the idea of ARM and also having a second architecture
because a mono-culture is never a good idea.

So in favour of supporting aarch64, we thought it is the best idea to say
goodbye to an architecture that will definitely die soon: x86 32 bit

> > 
> > 
> > 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.
> Hm, I see. Hope devices like Banana Pi and Wandboard will last some time...

Wandboard was never sold in good numbers. It is just way too expensive compared
to the SBCs like all the (fruit) pis, but at least they didn't change the design
which is good for us.

The cheaper boards are changing things all the time which essentially makes it
impossible to keep up with that. No distribution did that and in hindsight it
was a huge mistake to try this in the first place. We just had some hope and
thought the situation might improve. Unfortunately it didn't.

So don't expect anything from that end any more. We will let ARM 32 bit die,
too.

Let's hope for a better ARM 64.

> > > 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.
> Well, as Rod wrote in his mail, there might be some networks which consist of
> "legacy" systems. Here, it might be useful to post a message on the planet a
> month
> or so before discontinue support so they can upgrade.

We will not discontinue i586 for IPFire 2. So this isn't necessary.

If we would, even a year would not be enough for people to upgrade.

> > 
> > 
> > > 
> > > Sorry if there is a misunderstanding here - got way little coffe today. ;-
> > > )
> > > 
> > > Best regards,
> > > Timmothy Wilson
> > 
> > Best,
> > -Michael
> > 
> Best regards,
> Timmothy Wilson
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]