On 31 October 2013 08:10, Sam Kottler <skottler@redhat.com> wrote:


----- Original Message -----
> From: "David Nalley" <david@gnsa.us>
> To: "Fedora Cloud SIG" <cloud@lists.fedoraproject.org>
> Sent: Thursday, October 31, 2013 10:02:17 AM
> Subject: Re: ZOMG WHAT ARE WE BUILDING?!
>
> From the peanut gallery, feel free to treat accordingly.
>
> On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer <jwboyer@fedoraproject.org>
> wrote:
> > On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier <jzb@redhat.com> wrote:
> >> Hi all,
> >>
> >> (For those who weren't in today's IRC meeting, I sorta apologize for the
> >> subject line. Sorta.)
> >>
> >> As we were discussing today - we need to decide what we are building,
> >> and (almost as importantly) what we're not building. We've agreed that
> >> we want to be cooperating with the server SIG, but don't necessarily
> >> plan to build a foundation for an IaaS ourselves.
> >>
> >> Some of the questions that were raised during the meeting:
> >
> > Note:  I am a cloud newbie.  Please bear with my stupid questions.
> >
> >> - Should we drop 32-bit?
> >
> > I was under the impression that 32-bit guests on 64-bit hosts were
> > fairly common for applications where the advantages of 64-bit address
> > space isn't needed.  E.g. "64-bit python sucks a lot".  Maybe that's
> > becoming less of a concern?
>
> Agree - lots of situations where 32-bit is preferable, and in many
> cases still the defacto arch.

It's getting harder and harder to find 32 bit x86 hardware. There's exactly one use case for 32 bit in the cloud setting (IMO), which dgilmore and I briefly spoke about after the meeting yesterday - extremely memory constrained environments. The python memory consumption issues on 64 bit fall into that category. Does anyone have other use cases that aren't support for older hardware or memory usage with smaller amounts of mem?


Well the cloud instances aren't running on 32 bit hardware. The cloud server is probably 64 bit xen but the instances are 128MB -> 256 MB instances from what I can tell.  


--
Stephen J Smoogen.