One that strikes me as odd on that list is under "OpenWindows Libraries"
"... However, if required, the applications that use OpenWindows
Libraries can be run in Oracle Solaris 10 Zones"
I thought that the renumbering of zones was just that and not a
rebranding with libraries ... in fact I was pr
On Wed, Jun 22, 2011 at 4:05 AM, Jonathan Adams wrote:
> One that strikes me as odd on that list is under "OpenWindows Libraries"
>
> "... However, if required, the applications that use OpenWindows
> Libraries can be run in Oracle Solaris 10 Zones"
>
> I thought that the renumbering of zones was
32-bit still makes sense for an appliance. Unless you're seriously
_poor_, I don't see that it matters if it won't run on some old
dumpster diving relic.
And a point against it: UFS root support is also said to be going
away. That means ZFS root instead. And ZFS is really happier if
you have lo
In general, OpenWindows means two things to me:
libraries: libxview (XView toolkit), libXol (OLIT toolkit), and
associated libraries (libolgx and so on). The Open Look apps
went away at I think Solaris 9 (although most of them would still
run on Solaris 10 if one brought forward all the right bit
On 06/22/11 05:33 PM, Richard L. Hamilton wrote:
> And a point against it: UFS root support is also said to be going
> away.
UFS root is long gone - IPS only runs on a ZFS root, since it relies
on ZFS snapshots/boot environments. No OpenSolaris release ever had
UFS root support, nor does OpenInd
FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move
for modern operating systems since there are always going to be alternatives
for those still using i386 architecture. How long has Solaris/SPARC been
64-bit? At least ten years if not more...
-Gary
On 06/22/11 06:03 PM, Richard L. Hamilton wrote:
> Xsun: biggie for those of us with older SPARC hardware, lacking
> Xorg graphics driver support
>
> I may be wrong, but I thing I've seen things implying that at least
> a modest effort may be made to see that Xsun runs in a branded zone
> with the
Wow. They killed a lot of stuff. Not only 32-bit x86 support but tons
of other stuff too. SPARC Workstation support has been killed off (no
more UltraSparc I/II/III/IV support, no more Xsun and no more hardware
accelerated OpenGL for SPARC) and a lot of legacy peripheral support
for both x86 and SP
Closer to twenty. And my Ultra 1 is doing fine.
Sent from my iPad
On Jun 22, 2011, at 9:10 PM, Gary Driggs wrote:
> FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move
> for modern operating systems since there are always going to be alternatives
> for those still usi
On 23/06/11 11:52 AM, Michael Kerpan wrote:
Wow. They killed a lot of stuff. Not only 32-bit x86 support but tons
of other stuff too. SPARC Workstation support has been killed off (no
more UltraSparc I/II/III/IV support, no more Xsun and no more hardware
accelerated OpenGL for SPARC) and a lot of
On Wed, Jun 22, 2011 at 10:03 PM, McBofh wrote:
> On 23/06/11 11:52 AM, Michael Kerpan wrote:
>>
>> Wow. They killed a lot of stuff. Not only 32-bit x86 support but tons
>> of other stuff too. SPARC Workstation support has been killed off (no
>> more UltraSparc I/II/III/IV support, no more Xsun an
On Jun 22, 2011, at 7:19 PM, Ben Taylor wrote:
> I can almost see dumping 32-bit x86.
> but dumping 64-bit US-III/IV?
Use a kill-a-watt or a smart PDU to compare the power draw for these older
systems. Do you really want them in production? Solaris 10 isn't going away if
you do. q.v. several BS
You are absolutely correct. No one is going to put a 32 bit x86 system
into production. And no one is going to put an old 280R or V240
UltraSparc III system into production either.
But that's not the point. Jr. admins and hobbyist pick these boxes up.
They come from other hobbyist. They get p
Strategical decisions with not so large boundaries on the technical side, I
mean, they are not really saving much effort!
ZFS feeds on memoy like chupacabra does on blood, but still there is still
some life to those old 32 bit devices on the networking side of the game. We
dont trash servers so eas
On Wed, Jun 22, 2011 at 11:42 PM, Gary Driggs wrote:
> On Jun 22, 2011, at 7:19 PM, Ben Taylor wrote:
>
>> I can almost see dumping 32-bit x86.
>> but dumping 64-bit US-III/IV?
>
> Use a kill-a-watt or a smart PDU to compare the power draw for these older
> systems. Do you really want them in pro
June 2011 02:10
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for
solaris 11 will OI do same?
FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move
for modern operating systems since there are always going
likely because
> both BSD and Linux support lots of platforms outside of x86.
>
> Deano
>
> -Original Message-
> From: Gary Driggs [mailto:gdri...@gmail.com]
> Sent: 23 June 2011 02:10
> To: Discussion list for OpenIndiana
> Subject: Re: [OpenIndiana-discuss]
On Jun 23, 2011, Ben Taylor wrote:
> Personally, I wouldn't have signed up for a Kw based pricing scheme which you
> apparently did)
I didn't as it's one of many data centers that our company built and maintains.
I just prefer not to be an ass about resources.
-Gary
___
>> From: Gary Driggs [mailto:gdri...@gmail.com]
>> Sent: 23 June 2011 02:10
>> To: Discussion list for OpenIndiana
>> Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for
>> solaris 11 will OI do same?
>>
>> FWIW, Mac OS X Lion will onl
For Intel CPUs, 32 bit code is certainly more compact , and in some cases
arguably faster than 64 bit code. (say, comparing the same code on the same
machine
compiled 32 and 64 bit)
But, newer cpu silicon tends to make performance improvements
in many ways (e.g locating more supporting circui
The main difference is (in)ability to use large amount of RAM.
32-bit systems use 32-bit pointers, and maximum value of unsigned 32-bit
integer is 2^32,
or 4Gb. In practice many 32-bit OSes are able to address only 2Gb of RAM.
64-bit pointers can address much more RAM (no hardware has reached 2
So I guess it would be fair to say that the best OS is the one that
support both at the same time, and leaves the option to the developer
for each individual application.
My understanding is that Solaris is more like 4G per process/kernel,
rather than 4GB total.
Multiple 32 bit processes could use
I really can not make a case for 32 bit except for a legacy binary where you do
Not have a choice
Do we need a 32 bit kernel ?
Probably not. Do we need the ability
To run a 32 bit binary?I think so
-:::-sG-:::-
On Jun 24, 2011, at 12:17, Michael Stapleton
wrote:
> So I guess it would be fair
Steve Gonczi wrote:
I really can not make a case for 32 bit except for a legacy binary where you do
Not have a choice
Do we need a 32 bit kernel ?
Probably not. Do we need the ability
To run a 32 bit binary?I think so
Well, can't speak to opensolaris, but for 64-bit linux and windows, you
c
On 06/24/11 08:58 AM, Steve Gonczi wrote:
> For Intel CPUs, 32 bit code is certainly more compact , and in some cases
> arguably faster than 64 bit code. (say, comparing the same code on the same
> machine
> compiled 32 and 64 bit)
But 64-bit code has access to more registers, which can make a
> So I guess it would be fair to say that the best OS is the one that
> support both at the same time
Yes, and that's OSol and OI do.
On 24.06.2011 22:17, Michael Stapleton wrote:
So I guess it would be fair to say that the best OS is the one that
support both at the same time, and leaves the o
On Jun 24, 2011, at 4:17 PM, Dmitry Kozhinov wrote:
> > So I guess it would be fair to say that the best OS is the one that
> > support both at the same time
>
> Yes, and that's OSol and OI do.
Processes running under 32-bit Solaris can only be 32-bit.
Processes running under 64-bit Solaris can
Michael Stapleton wrote:
While we are talking about 32 | 64 bit processes;
Which one is better?
Faster?
More efficient?
Initially, assuming a 32 verses 64 bit build doesn't change any
algorithms...
On x86, a 64 bit build of the same program will typically run ~50%
faster if it's CPU-bound
28 matches
Mail list logo
