> I would say there are many systems 32-bit only (and there is some
> probability even 32-bit SPARC kernel will return).
This is absolutely not the case.
- Bart
--
Bart Smaalders Solaris Kernel Performance
ba...@cyber.eng.sun.com http://blogs.sun.com/barts
"You will c
casper@sun.com wrote:
>
>> CR 6248065 is quite interesting. However, some reasons from 2005 aren't
>> much applicable nowadays (system is more-or-less 64-bit-proof now).
>> And well, maybe it's not about optimization, it's more about policy for
>> using isa directories.
>
>
> In SPARC, we
Hi Casper,
V po, 09. 02. 2009 v 18:23, casper@sun.com píše:
>
> AFAIK, when we first did "64-bit" SPARC, Kenbus was a very important
> benchmark; it suffered when ls needed to use "isaexec".
>
> My memory could be failing, though.
>
I cannot argue for or against, my memory is shorter :-)
Hi Alex,
V po, 09. 02. 2009 v 18:21, Alexander Vlasov píše:
> Hello,
>
> CR 6248065 is quite interesting. However, some reasons from 2005 aren't
> much applicable nowadays (system is more-or-less 64-bit-proof now).
I would say there are many systems 32-bit only (and there is some
probability ev
>CR 6248065 is quite interesting. However, some reasons from 2005 aren't
>much applicable nowadays (system is more-or-less 64-bit-proof now).
>And well, maybe it's not about optimization, it's more about policy for
>using isa directories.
In SPARC, we can really get rid of much of the isaexec
AFAIK, when we first did "64-bit" SPARC, Kenbus was a very important
benchmark; it suffered when ls needed to use "isaexec".
My memory could be failing, though.
Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Hello,
CR 6248065 is quite interesting. However, some reasons from 2005 aren't
much applicable nowadays (system is more-or-less 64-bit-proof now).
And well, maybe it's not about optimization, it's more about policy for
using isa directories.
SDL case is absolutely unclear: if one knows which IS
Great!
uploaded to Nexenta APT now, for NCP2 users just do:
# apt-get install ndmpcopy
On Sun, 2009-02-08 at 17:46 -0800, Ben Rockwood wrote:
> Vilas Deshpande, I love you!!! Thank you! I've been needing this badly!
>
>
> benr.
>
> ___
> storage-d
Hi,
V po, 09. 02. 2009 v 16:05, casper@sun.com píše:
> >However, in OpenSolaris I can see few deviations from this principle:
> >/usr/bin/amd64 contains more binaries than /usr/bin/i86 and
> >/usr/bin/pentium_pro+mmx together; for example, take a look at `ls' or
> >`sdl-config':
> >
> >/usr
>Hi,
>
>i'm not sure if it is really necessary to have all the GNU tools
>preferred over Solaris tools. The most user expect GNU behaviour of tar
>(-z, -j), grep (-r), find (-iname, . as default path) and may be some
>other tools. But for ls, chmod and df (zfs) i assume the most GNU
>familiar user
> In
> Martin Bochnig wrote:
> On Sun, Feb 8, 2009 at 3:21 AM, NAKAJI Hiroyuki wrote:
> >> In <4cb4ba740902031244s18d61999ye748345fce315...@mail.gmail.com>
> >> Al Hopper wrote:
> >
> >> osol-0906, based on build 106a, is available on genunix.org.
> >
> > Thanks for the sna
Mr Napon Isaac
Officier de Crédit /Change et
Recouvrements des Fonds à la Bank
Of Africa (BOA).Ouagadougou
Burkina Faso
Bonjour,
Je m'appelle Mr Napon Isaac,employé à la Bank Of Africa du Burkina Faso(BOA
BF),en tant que officier du département de crédit et de rémittence
internationale. Je v
>>
> Have you tried an upgrade?
>
> That would be one way to see if the problem is with the b105 code base
> or with the installer.
>
Yes, I did get it upgraded to B105, so it looks like an installer issue
to me.
___
opensolaris-discuss mailin
Joerg, you're right, I think I copied from an old post of mine without
double checking, sorry for it. By the way, I was just saying that I
remember I was hit by that issue little more than a years ago: I began
to correlate things when you cited larger sparse files and
multivolumes.
By the way, tha
On Sun, Jan 18, 2009 at 12:31 AM, Alan Coopersmith
wrote:
>
> Enrico Maria Crisostomo wrote:
>> On Fri, Jan 16, 2009 at 7:35 PM, Alan Coopersmith
>> wrote:
>>> Brian Smith wrote:
If a GNU utility is a proper superset of the Solaris version, would patches
to replace the Solaris version w
For as rare as such an event could be, I was affected by this: more
than once GNU tar couldn't extract it's own files while fortunately
pax could. I had to back up some big directories with GNU tar on
Solaris 10 and sometimes it happened that tar exited with exit status
0 doing nothing. Archives we
On Sat, 17 Jan 2009 23:03:12 +0100
Mika Borner wrote:
> We should not forget that Apple welcomes users with a BSD userland. Many
> developers also use Mac OS X as their preferred platform. And almost
> everybody seems quite happy with it...
This isn't quite true. Yes, OSX is fundamentally a BSD
[ I've moved opensolaris-discuss to the Bcc ]
> The utilities in question do not support Linux specific features. Why do you
> believe you will be able to feed back such enhancements for Solaris to the
> upstream?
Is it your personal experience that this is the case or can you point
to mail archi
On Fri, 16 Jan 2009 19:04:03 -0800 Bart Smaalders
wrote:
> Mike Meyer wrote:
> > On Fri, 16 Jan 2009 17:42:00 -0500 (EST) Dennis Clarke
> > wrote:
> >> If the Solaris commands become a superset of the Gnu ones, then that
> >> position becomes a fait accompli.
> >
> > Thus avoiding the entire
On Fri, 16 Jan 2009 17:42:00 -0500 (EST) Dennis Clarke
wrote:
> If the Solaris commands become a superset of the Gnu ones, then that
> position becomes a fait accompli.
Thus avoiding the entire question of whether or not that's the best -
or even a desirable - goal.
http://www.m
On Fri, Jan 16, 2009 at 7:35 PM, Alan Coopersmith
wrote:
>
> Brian Smith wrote:
> > If a GNU utility is a proper superset of the Solaris version, would patches
> > to replace the Solaris version with the GNU version be accepted?
>
> I would think so, but it would depend on specific cases.
>
> > Or
On Wed, 14 Jan 2009 13:54:15 -0600 (CST) "David Dyer-Bennet"
wrote:
> On Wed, January 14, 2009 13:39, Fredrich Maney wrote:
> > I agree with one caveat: the native fully supported and integrated Sun
> > tools should be come first the default PATHs when shipped and
> > modifying that value should
Hi,
i'm not sure if it is really necessary to have all the GNU tools
preferred over Solaris tools. The most user expect GNU behaviour of tar
(-z, -j), grep (-r), find (-iname, . as default path) and may be some
other tools. But for ls, chmod and df (zfs) i assume the most GNU
familiar users would
>However, in OpenSolaris I can see few deviations from this principle:
>/usr/bin/amd64 contains more binaries than /usr/bin/i86 and
>/usr/bin/pentium_pro+mmx together; for example, take a look at `ls' or
>`sdl-config':
>
>/usr/bin/amd64/ls is 64-bit binary
>/usr/bin/i86/ls is not present
>/usr
Hello,
according to isaexec manual page, it traverses the list for an
executable file in subdirectories of the original directory, named
according to isalist output. When such a file is located, execve() is
invoked with argv[] and envp[].
So to make OS autoselect appropriate binary for p
25 matches
Mail list logo
