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
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
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
On Wed, 14 Jan 2009 13:54:15 -0600 (CST) David Dyer-Bennet d...@dd-b.net
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
On Fri, Jan 16, 2009 at 7:35 PM, Alan Coopersmith
alan.coopersm...@sun.com 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
On Fri, 16 Jan 2009 17:42:00 -0500 (EST) Dennis Clarke dcla...@blastwave.org
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.
mike
On Fri, 16 Jan 2009 19:04:03 -0800 Bart Smaalders bart.smaald...@sun.com
wrote:
Mike Meyer wrote:
On Fri, 16 Jan 2009 17:42:00 -0500 (EST) Dennis Clarke
dcla...@blastwave.org wrote:
If the Solaris commands become a superset of the Gnu ones, then that
position becomes a fait accompli.
[ 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
On Sat, 17 Jan 2009 23:03:12 +0100
Mika Borner opensola...@bluewin.ch 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
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
On Sun, Jan 18, 2009 at 12:31 AM, Alan Coopersmith
alan.coopersm...@sun.com wrote:
Enrico Maria Crisostomo wrote:
On Fri, Jan 16, 2009 at 7:35 PM, Alan Coopersmith
alan.coopersm...@sun.com wrote:
Brian Smith wrote:
If a GNU utility is a proper superset of the Solaris version, would patches
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,
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 mailing list
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
In c2315a540902072109t74f0c0ej3229a622ad...@mail.gmail.com
Martin Bochnig mar...@martux.org wrote:
On Sun, Feb 8, 2009 at 3:21 AM, NAKAJI Hiroyuki nak...@heimat.jp wrote:
In 4cb4ba740902031244s18d61999ye748345fce315...@mail.gmail.com
Al Hopper a...@logical-approach.com wrote:
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
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':
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-discuss
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
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
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
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 even
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 :-)
Best
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 can really
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
25 matches
Mail list logo
