[OpenIndiana-discuss] 32-bit support in OpenIndiana Hipster

[Nikola M]

On 02/16/15 11:06 AM, Alexander Pyhalov wrote:
> Hello.
>
> We currently support (in some way) 32-bit systems. We avoid shipping 
> 64-binaries in default path or use isaexec for such things.
> But do we really need it? I haven't seen PC (not speaking about 
> server) without 64-bit CPU for at least 8 years.
>
> Dropping support for 32-bit systems will allow us to port Oracle 
> sources easier. Potentially, this solves time_t overflow. We could 
> think about largefile support less.
>
> What are the cons of keeping support for 32-bit systems? I don't see 
> much. If you see them, please, speak now.
32-bit user-base is simply too large to ignore. OI needs all users it 
can get.

OI Hipster (e.g. OI rolling release) needs at least ONE stable release 
that IS upgreadable from existing /dev releases directly, before 
breaking support for large user base as 32-bit x86 CPUs (and VMs) are.

On positive side, illumos will definitively switch from support 32-bit 
CPUs to moving it
(32bit driver, as I understand, and application support stays!) , to 
some time in the future.
The same will happen to OI, e.g. moving to maintenance mode for 32-bit 
CPU support.

But OI needs prooved, stable , updated release before that happens, not 
ever-breaking rolling release model without even release numbers to test it.
>
> I'm inclined to make changes, breaking 32-bit systems only after next 
> ISO snapshot. Of course, 32-bit libraries will be preserved.

I see community voiced it as Nay for now. There's user base that is 
concerned with that move now.

I think there are more important things to do first,
as per example , NUMBERING Hipster updates , so that Testing of rolling 
release updates are actually - Releases, and not only random updates one 
only can chase from one ISO "freeze" to another.
Freezing and making ISO should be on something usable and tested and 
something stable, not just freezing bugs and unable to do regular 
update, like it is with 20141010 now.
Freezes to Hipster actually happen because of Hipster build process that 
is building and updating ALL packages ALL the time, that is genrelly not 
needed (As I know too, IPS is able to update only CHANGED files inside 
packages not all files in packages, making Hipster updates very large)

Also updating from /dev to some OI Hipster Release (not just freeze) 
could be said is mandatory, because Hipster is part of OI and not 
separate distro and without continuity with /dev it is beheading OI's 
reputation and userbase left.
Making numbered Hipster updates , promoting testing before Hipster 
releases and have tested way of updating from /dev is path to having 
Maintance release that could be supporting 32-bit CPUS,
as planned in illumos , not just "Breaking 32-bit systems in random ISO 
snapshot".