Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
- KB
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
On 24 January 2014 15:29, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64
clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
EPEL is built against the binaries from Red Hat Enterprise Linux so the architectures we have supported in the past have been only the ones they support (x86_64, i686, ppc64) with EL7 we are currently focusing on x86_64 and ppc64. I do not know at this time what issues we would need to get a CentOS tree in our build system.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Jan 24, 2014, at 4:29 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
Todd
On 24 January 2014 16:00, Todd Rinaldo toddr@cpanel.net wrote:
On Jan 24, 2014, at 4:29 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64
clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
There are several items I see i686 support being needed:
1) Memory is not cheap in cloud and hosted environments. Especially in cloud where you might be firing up a thousand hosts at a time. 2) Multiple Virtual Machines don't do well in the transition from 32 bit to 64 bit in that their memory usage doesn't go up by *2 but can be ^2 depending on the workload. Python is a perfect example of this but there are cases in java and other 'virtual machine' environments where it happens. 3) As nice as having i686 compat libraries are for some commercial apps you end up needing a lot more than what is provided by the OS. This really comes up when you have to run a mixed set of commercial binaries that need something that only EL7 provides but also needs stuff that EL6 had. Thus you end up needing i686 everything.
On 01/25/2014 01:32 AM, Stephen John Smoogen wrote:
On 24 January 2014 16:00, Todd Rinaldo <toddr@cpanel.net mailto:toddr@cpanel.net> wrote:
On Jan 24, 2014, at 4:29 PM, Karanbir Singh <mail-lists@karan.org <mailto:mail-lists@karan.org>> wrote: > On 01/24/2014 10:26 PM, Manuel Wolfshant wrote: >> On 01/25/2014 12:13 AM, Karanbir Singh wrote: >>> Hi >>> >>> Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even >>> going to be a multilib attempt or is everything going to stay x86_64 clean ? >> they build for x86_64 and ppc64 only, > > So then the question is - what is the process to enable i686 there ( or, > do we then need to own all of EPEL - atleast some subset ) locally if we > are going to attempt a i686 CentOS build ? > > - KB Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?There are several items I see i686 support being needed:
- Memory is not cheap in cloud and hosted environments. Especially in
cloud where you might be firing up a thousand hosts at a time. 2) Multiple Virtual Machines don't do well in the transition from 32 bit to 64 bit in that their memory usage doesn't go up by *2 but can be ^2 depending on the workload. Python is a perfect example of this but there are cases in java and other 'virtual machine' environments where it happens. 3) As nice as having i686 compat libraries are for some commercial apps you end up needing a lot more than what is provided by the OS. This really comes up when you have to run a mixed set of commercial binaries that need something that only EL7 provides but also needs stuff that EL6 had. Thus you end up needing i686 everything.
for what is worth I have some _expensive_ EDA tools from Incisive which bundle 64bit binaries in the supposedly 32bit toolchain as well as an IBM tool which requires a 32bit OS lib in its _64_bit toolchain....
On 01/24/2014 11:32 PM, Stephen John Smoogen wrote:
There are several items I see i686 support being needed:
Then there is the case where we need to build large chunks of 32bit code to satisfy the requires for the multilib components in x86_64 as well.
So it might end up being an easy win to extend that, wrap the installer around the repo and bob's your uncle. Now, why and where people are going to use it is upto them, and I am hoping that the entire 32bit tree becomes community run ( the builds so far, definitely have been )
- KB
On 01/25/2014 12:00 AM, Todd Rinaldo wrote:
On Jan 24, 2014, at 4:29 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
Todd
As I can see, so far, RHEL 7 has minimum hardware requirements very close to 6.x, at least for the Desktop/Workstation use.
In developing countries there is still lots of 32-bit hardware that will not be thrown away just because 64-bit is better. If there is no 32-bit version, all of those using 32-bit systems now will either stay with 6.x or move to Something that provides 32-bit distro version like Ubuntu. I expect that hardware will be around for another 3-5 years, just until RHEL 8 is out.
Also, Embedded systems mostly have 32-bit processors, as far as I know, not needing 64-bit ones, so it would be nice to use CentOS on them, not some other distro.
On 01/25/2014 01:33 AM, Ljubomir Ljubojevic wrote:
On 01/25/2014 12:00 AM, Todd Rinaldo wrote:
On Jan 24, 2014, at 4:29 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
Todd
As I can see, so far, RHEL 7 has minimum hardware requirements very close to 6.x, at least for the Desktop/Workstation use.
In developing countries there is still lots of 32-bit hardware that will not be thrown away just because 64-bit is better. If there is no 32-bit version, all of those using 32-bit systems now will either stay with 6.x or move to Something that provides 32-bit distro version like Ubuntu. I expect that hardware will be around for another 3-5 years, just until RHEL 8 is out.
+1
Also, Embedded systems mostly have 32-bit processors, as far as I know, not needing 64-bit ones, so it would be nice to use CentOS on them, not some other distro.
+1 as well. So far I had to run linaro on all my ARM boards.
On Fri, Jan 24, 2014 at 5:39 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Also, Embedded systems mostly have 32-bit processors, as far as I know, not needing 64-bit ones, so it would be nice to use CentOS on them, not some other distro.
+1 as well. So far I had to run linaro on all my ARM boards.
There's probably also still a case for LTSP - PXE booting thin clients with an image from the server - and the ability to use older machines as the clients. Even the PAE requirement of 6.x was problematic for that.
On 01/25/2014 12:46 AM, Les Mikesell wrote:
On Fri, Jan 24, 2014 at 5:39 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Also, Embedded systems mostly have 32-bit processors, as far as I know, not needing 64-bit ones, so it would be nice to use CentOS on them, not some other distro.
+1 as well. So far I had to run linaro on all my ARM boards.
There's probably also still a case for LTSP - PXE booting thin clients with an image from the server - and the ability to use older machines as the clients. Even the PAE requirement of 6.x was problematic for that.
+1
On 01/25/2014 12:39 AM, Manuel Wolfshant wrote:
On 01/25/2014 01:33 AM, Ljubomir Ljubojevic wrote:
On 01/25/2014 12:00 AM, Todd Rinaldo wrote:
On Jan 24, 2014, at 4:29 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
On 01/25/2014 12:13 AM, Karanbir Singh wrote:
Hi
Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even going to be a multilib attempt or is everything going to stay x86_64 clean ?
they build for x86_64 and ppc64 only,
So then the question is - what is the process to enable i686 there ( or, do we then need to own all of EPEL - atleast some subset ) locally if we are going to attempt a i686 CentOS build ?
- KB
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
Todd
As I can see, so far, RHEL 7 has minimum hardware requirements very close to 6.x, at least for the Desktop/Workstation use.
In developing countries there is still lots of 32-bit hardware that will not be thrown away just because 64-bit is better. If there is no 32-bit version, all of those using 32-bit systems now will either stay with 6.x or move to Something that provides 32-bit distro version like Ubuntu. I expect that hardware will be around for another 3-5 years, just until RHEL 8 is out.
+1
Also, Embedded systems mostly have 32-bit processors, as far as I know, not needing 64-bit ones, so it would be nice to use CentOS on them, not some other distro.
+1 as well. So far I had to run linaro on all my ARM boards.
ARM are another matter.
But Alix boards for example use x86 AMD Geode LX CPU ("All that should be required is a kernel patched to emulate the nopl instruction in software. The Geode LX has everything required for i686 except that instruction."), etc.
-
Karanbir Singh -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Stephen John Smoogen -
Todd Rinaldo