On 01/25/2014 01:32 AM, Stephen John Smoogen wrote: > > > > On 24 January 2014 16:00, Todd Rinaldo <toddr at cpanel.net > <mailto:toddr at cpanel.net>> wrote: > > > On Jan 24, 2014, at 4:29 PM, Karanbir Singh <mail-lists at karan.org > <mailto:mail-lists at 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. 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.... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140125/ddf3bf79/attachment-0007.html>