First of all, I have several 32-bit computers in production, and I
would like to be able to install and run OpenIndiana on them, but I
cannot demand that anyone donate his time to accommodate my wishes.
I mention this only if the volunteers are curious to know whether
anyone would use 32-bit OpenI
Hello,
> Why not deliver amd64 bits in /usr/bin ? If we deliver them in
> /usr/bin/amd64, they are not in default PATH,
> and we have to use isaexec. I don't see good reason for this. We can
> deliver them in /usr/bin/amd64 and hardlinks
> in /usr/bin, but I don't see benefits from doing this.
>
Aurélien Larcher писал 23.01.2016 21:20:
We are going to follow the path which was chosen by Oracle in
userland-gate.
Basic macroses are not touched. Compilers still produce 32-bit
binaries by
default. 64-bit binaries are produced when necessary and delivered in
/usr/bin
if 32-bit binaries are
> We are going to follow the path which was chosen by Oracle in
> userland-gate.
> Basic macroses are not touched. Compilers still produce 32-bit binaries by
> default. 64-bit binaries are produced when necessary and delivered in
> /usr/bin
> if 32-bit binaries are not present. We'd like to avoid d
Alexander Pyhalov писал 23.01.2016 08:21:
OmniOS and Dilos already doesn't claim to support 64-bit binaries.
Dilos I think is closer to us,
Need to sleep more. I mean don't support 32-bit systems.
---
System Administrator of Southern Federal University Computer Center
As there were several comments, I'd like to clarify the plan and answer
some questions.
The overall goal is to decline less from upstream userland-gate and
x-s12-clone.
We are going to follow the path which was chosen by Oracle in
userland-gate.
Basic macroses are not touched. Compilers stil
Hello,
>
> I saw no call for discussion, only an official statement that 32-bit
> support is dropped.
>
There is such thing as "official statement" here, just volunteers
evaluating what can be achieved in a realistic way and given the demand.
>
> If the source for the installer is there, it's w
On Fri, Jan 22, 2016 at 3:59 PM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:
> This discussion is actually a call for devising an organized plan !
> So what are you complaining about ?
>
I saw no call for discussion, only an official statement that 32-bit
support is dropped.
> So sinc
On 01/22/16 01:23 PM, Tim Mooney wrote:
In regard to: Re: [OpenIndiana-discuss] 32-bit support in OpenIndiana...:
On the other hand, to properly utilize the attractive feature of
transparently supporting both
32-bit and 64-bit systems via isaexec,
When there was a giant corporation funding de
> > The next OI Hipster snapshot will no pretend to support 32bit CPUS.
The question is here, booting the 32-bit Kernel. That might be abandoned.
32-bit programs can continue to run as well as 64-bit programs
If the question is about changing the directory layout, I would vote
for *don't* change
In regard to: Re: [OpenIndiana-discuss] 32-bit support in OpenIndiana...:
On the other hand, to properly utilize the attractive feature of
transparently supporting both
32-bit and 64-bit systems via isaexec,
When there was a giant corporation funding development, isaexec was a neat
feature. N
>
>
>> Obviously, unilaterally dropping 32-bit support by providing only 64-bit
>> components also breaks binary compatibility on 32-bit systems, as those
>> systems are unable to run 64-bit executables or link 64-bit libraries
>> into 32-bit executables.
>>
>
> Seriously, I wrote ship 32bit when i
>
> Obviously, unilaterally dropping 32-bit support by providing only 64-bit
> components also breaks binary compatibility on 32-bit systems, as those
> systems are unable to run 64-bit executables or link 64-bit libraries
> into 32-bit executables.
>
Seriously, I wrote ship 32bit when it makes se
> > Hello,
> >
> > There's something wrong with this picture...
> > >
> >
> > I do not think there is, considering that I was asking about the long
> term
> > goal and not providing a transition recipe to be implemented right away.
> >
>
> The problem that I see is that there is neither an organize
On Fri, Jan 22, 2016 at 2:57 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> On 01/22/16 11:32 AM, Bruce Lilly wrote:
>
>> 1. time_t (via illumos; this shouldn't be rocket science -- both NetBSD
>> and
>> OpenBSD have
>> 64-bit time_t on both 32- and 64-bit systems)
>>
>
> OpenBS
On Fri, Jan 22, 2016 at 3:00 PM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:
> Hello,
>
> There's something wrong with this picture...
> >
>
> I do not think there is, considering that I was asking about the long term
> goal and not providing a transition recipe to be implemented right a
Hello,
There's something wrong with this picture...
>
I do not think there is, considering that I was asking about the long term
goal and not providing a transition recipe to be implemented right away.
>
>
>
> So if your goal is really to drop 32-bit support (and thereby alienate
> those with
22 января 2016 г. 18:03:14 CET, Alexander Pyhalov пишет:
>On 02/16/2015 13:06, 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
There's something wrong with this picture...
Although OI inherited isaexec and *could* ship both 32- and 64-bit
executables and libraries,
presently only 32-bit libraries are available in many cases (e.g. gamin).
Also, the default
compilation on 64-bit systems produces 32-bit executables (and libr
Hello,
> Today I've shipped PostgreSQL 9.5. AMD64 version still doesn't have
> PL/Perl support, because we ship 32-bit Perl. The next Perl version which
> we ship will be 64-bit only. I don't think there's much benefit in
> supporting 32bit systems. So, consider this an official statement.
>
> Th
On 02/16/2015 13:06, 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.
Centuries ago, Nostradamus predicted that Alexander Pyhalov would
write on Mon, 16 Feb 2015 13:06:06 +0300:
>
> 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
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 year
I was meaning to compose something to this effect, but Peter, you've put
it perfectly.
Despite personally having moved off of 32-bit in the nineties, I agree
with Peter and would rather see 32-bit remain for now.
Might come in handy for the ARM port, too ;)
--jake
On Tue, Feb 17, 2015 at
On Mon, Feb 16, 2015 at 10: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
I don't personally use NDIS for my wireless (I bought Intel to make sure I
didn't) but if this is still being used by anyone then 32-bit support is
generally mandated for a lot of that.
Apart from that, I still have Solaris 10 for 32-bit, and an Ubuntu install
server for anything more ancient (pre
16 февраля 2015 г. 11:06:06 CET, Alexander Pyhalov пишет:
>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
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 f
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 all
29 matches
Mail list logo
