Re: Question concerning the IDS2016 log

[Michael Tremer <michael.tremer@ipfire.org>]

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