On Mon, Mar 22, 2010 at 9:53 PM, Neal Pollack
Neal.Pollack at sun.com wrote:
If welcome here is PSARC
No, it is the OpenSolaris ARC community alias, which
PSARC-ext feeds into.
I don't really care what goes on inside the
proprietary PSARC at sun.com
as it reviews closed cases - as
I'm still hoping SIGINFO will find its way back into existence. That's just one
signal, hopefully there's plenty of room for it...
--
This message posted from opensolaris.org
Caution: random thoughts follow.
For situations like this where there's some question as to what can be
expanded or extended with minimal impact, why not have someone write
a DTrace script that collects info (program name, relevant system call usage)
needed to spot likely problem applications if
why not carry on to the logical conclusion, i.e. full fat binaries
(x86/amd64/sparcv7/sparcv9)?
--
This message posted from opensolaris.org
Is the user SID also in audit output? If it isn't, shouldn't it be, if
available, esp.
if the UID is ephemeral? Wouldn't it be worth recording for forensics?
--
This message posted from opensolaris.org
Random thoughts:
* revoking a basic privilege falls under the category of buyer beware;
introducing a new
basic privilege by itself doesn't break anything, rather, it's revoking it
that might break
something.
* IMO, Casper's point that Solaris 8 could achieve this with an ACL on /dev/tcp
My concern with using it to accelerate non-volatile
storage
is partly with the prospects for human error
(adapter cord
to trip over, command that needs to be run), but
also
The DDRdrive X1 ACDC power cord exits the rear of the
chassis just
as the host power supply cord, if a customer
This device seems completely unsuitable for use as a
ZFS slog as it is
described in this case. The ZFS log isn't just there
for the case where
we loose power but also for the (hopefully even
rarer) cases where the
operating system panics. How would this device work
in that case [ with
[...]
For the record, I'm not entirely convinced that
including nmap was a
good idea either, but at least its probes are
non-destructive in nature.
[...]
At one time (still on unpatched/legacy systems), nmap could mess up inetd,
requiring manual intervention; although it's not _intended_ as
I don't see it stated, but I would hope that an attempt to manipulate a
process (LWP actually, I suppose) in SDC class would fail with the same errno
as would an attempt to manipulate a process in SYS class.
There is bound to be code out there that assumes that if the scheduling class
!= SYS,
Funny that even back in Solaris 8 days I had no trouble getting Sun lp/lpsched
to
support just about every one of the lpr filter types. Some (like the Fortran
control
characters, still used in some Fortran programs) are trivial and can be done
with an existing program (asa) and just a new
Note also that users who might still have such ancient hardware (or want
to plot to a terminal device) might find they are able to plot to it using
the gnuplot command, which has output drivers for it. (Gnuplot is not yet
integrated, but this is expected as it was approved as part of PSARC
On the existing zfs man page, I see the text:
The format of the stream is evolving. No backwards compati-
bility is guaranteed. You may not be able to receive your
streams on future versions of ZFS.
But I see no similar warning for zstreamdump, nor an explanation
as to why that warning does
Personally, I _am_ a bit bothered by behavior that increases the
memory footprint. Consider virtualization: one may well want to
run virtual machines with as little memory as they strictly need,
since that's very easily adjustible, and since the less each guest
uses, the more remains for other
Is this intended to be something like the
conditional symbolic links that have
been in Apollo Domain system 23 years ago?
I'm not familiar with that proposal. Can you provide
details?
Thanks,
Alan
As I recall, Apollo Domain OS implicitly made environment variables available
John Plocher wrote:
On Tue, Jun 9, 2009 at 5:54 PM, Jerry Gilliam
jerry.gilliam at sun.com wrote:
For the minor (major?) release only, I think it
would be reasonable to
modify iostat(1M) to -n behavior by default,
effectively obsoleting
-n and the driverinstance form of device name
[...]
We're seeking Minor binding at the moment, as we have concrete plans
to backport this. We do believe that at some point in the future it
[...]
I assume you meant _no_ concrete plans.
--
This message posted from opensolaris.org
On May 14, 2009, at 5:48 PM, Edward Pilatowicz wrote:
this is great.
i just have one question. is there anyway to undo
a zfs destroy -d
request? (it seems to me that if zfs destroy -d
was implmented in
terms
of a snapshot property, say autodelete=on|off, this
would be easy.)
According to the interface table, it looks like there
is one
binary- pdsh, which will be /usr/local/pdsh.
It's not just /usr/local/bin - Solaris has never had a /usr/local, period.
Even end user sites sticking stuff in /usr/local is arguably wrong (/usr being
meant to be entirely fair game in
[...]
If it's the GUI that they'll use, I'd expect that all
you need is to
have the path name '/usr/sbin/gparted' made Committed
(probably not
this case). If it's the command line, then it's
'/usr/sbin/parted'
plus perhaps one or two of the command-line options.
[...]
If it's expected to
Are you actually improving GCC performance on
Solaris by modifying GCC?
Yes, by hooking up the GCC frontends with the
Studio Sparc backends.
The plain GCC backend will be available under flag
control.
[...]
I've heard claims of Studio outperforming GCC on x86, as well. Has something
Why exclude GCJ (i.e. the Java compiler) and GNAT
(Ada compiler)?
Objective C++ may be inappropriate, on the other
hand: it is not built by
default, its future maintenance is highly uncertain,
so it may be better
not to include it in the first place.
Why do you say its future maintenance
[...]
(not that I'm asking for that; but it seems like
something that a random volunteer could).
s/could/could do easily enough/
--
This message posted from opensolaris.org
Hi,
Kais, the thing is that I don't need to install
ndbm.h and dbm.h at all.
I can install gdbm.h only (so there would be no need
to create gdbm
directory).
As the time goes I think that removing those
compatibility files and
installing gdbm.h only directly to the /usr/include/
is a
Do the issues in the section of the page
http://4front-tech.com/pguide/audio2.html#syncro
(Synchronization issues) generally apply to Boomer as well?
And if there presently isn't a way to specify fragment characteristics
(interrupt per N frames, I think you define that as), is that anticipated
Should the real-time programming documentation be updated to
mention this?
--
This message posted from opensolaris.org
Darren J Moffat Darren.Moffat at sun.com wrote:
in the architecture of Solaris. As others have
asked how does this help
Solaris ? I really think this belongs as part of
NetBeans more than
Solaris.
I also really dislike the very generic
/usr/bin/findbugs name given what
this
On 09/03/08 17:07, Vikram Hegde wrote:
Hi,
Abilities to disable the IOMMU as a choice?
Performance impact on
various systems and interactions with other
projects that have gone
to some length to work within S/G and its
performance
characteristics. How will this affect them?
IMO, rfb is a _very_ bad choice of driver name, given the confusion possible
with the RFB protocol used by VNC (and for which I think there is an X.org
loadable
module).
That quite aside from any issues of continuity with existing driver names...
--
This message posted from opensolaris.org
Richard L. Hamilton rlhamil at smart.net wrote:
You may want to reconsider the notion of merging
them, unless a _lot_ of
work was done, and go with just having both,
distinct, instead. ISTR discussion
(Usenet?) of top being a pig with lots of
processes, because it didn't hold
Darren J Moffat Darren.Moffat at Sun.COM wrote:
GNU find should be integrated as it is upstream
except for any changes
necessary to make it compile and run on Solaris.
If there are generic
bugs/issues like the one you described it isn't upto
*this* project team
to fix them. That
Curious why -key and -mod instead of (or in addition to) traditional libXt
translation table syntax, which could be given with a single option having a
value like
ShiftKeyF5 (and could perhaps even handle modifiers and mouse buttons).
Of course, with all the gtk and Qt stuff, maybe libXt is just
[...]
Why is this different from the PCI-related tools?
As someone who might use this, I see some differences about USB:
* USB is _routinely_ hot-pluggable, typically by end users (although the
ability to
lock it down would certainly be desirable in some settings)
* it doesn't necessarily
* Depending on how clean the implementation is, I'd think a command-line
in addition to the GUI should also be possible, and the less prerequisites it
had,
the earlier it could be used in installation.
* Would be nice if the server URLs were configurable, for isolated networks
that kept their
Volatile, externally controlled, that's the price of admission on this one, ok.
That they provide it at all is better than that they don't, and adding it so the
end user doesn''t have to hunt for it and/or has a similar experience as on
other
platforms, may be desirable. (I trust it's
fyi, ICA clients for Solaris (both SPARC and x86) appear to be available
from Citrix, for free assuming my cursory exploration of download.citrix.com
didn't mislead me.
This message posted from opensolaris.org
I'd be shocked to find anyone has expect scripted
sulogin (possibly
excepting some test code here inside Sun to test
failure scenarios,
although even that seems doubtful).
When sulogin is invoked, the machine is typically
already at the point
of failure, and its hard to imagine people
In this case, the 32 bit versions have capacity
limits that are
affecting Roland and he wishes to remove those
limits. This
is not at all a performance issue, but a make it work
better one.
Last I heard, unless there was some benefit to be gained, 64-bit was usually
_slower_ on SPARC than
Glenn Skinner wrote:
Date: Fri, 30 May 2008 15:19:45 -0700 (PDT)
From: Matthew Ahrens ahrens at sac.sfbay.sun.com
Subject: zpool autoexpand property
[PSARC/2008/353 Self Review]
...
B. PROBLEM
With the addition of Dynamic LUN Expansion
(PSARC 2006/373),
I am sponsoring this case for Kenichiro Kagoshima.
Timeout is set for
6/04/08.
The functional spec is in the case directory.
Release binding is Minor.
minor, not patch (i.e. no plans to backport)? Bummer...
This message posted from opensolaris.org
This seems rather complicated to me. Given that
SAM-QFS SMF Management of sam-fsd (PSARC/2008/326)
was recently approved, why can't svc:/system/zones:default
be made to depend ultimately on SAM-QFS already being up
(whether via the milestone that it currently depends on, or directly)?
Or if
Speaking of squashing, there have been multiple
attempts to publicly
expose these
symbols. The rationale is that third party libraries
could use the same
trick - by
binding to _read() rather than read(). That trick
has merit, but I
don't think it ever
happened.
(Bart, I think you
[...]
In my mind, EVERY SINGLE FOSS project out there[1]
should be available
in a repository, in ready-to-run binary form, waiting
for someone who
needs it to download on their OpenSolaris system.
Now, if you were saying only *some of them* should
be considered
candidates to become a
Hi Dan,
Can you explain what is the relationship (if any)
between /usr/bin/rsync and
librsync ?
Would it be possible to build /usr/bin/rsync by
linking to this library as
seems sensible?
Trev
According to http://librsync.sourceforge.net/
I would think not; the principle is similar
Would it be possible to enable the functionality automatically when rules
using it are loaded?
This message posted from opensolaris.org
I've made the opinion of PSARC 2002/348
[International Components for Unicode
(ICU)] publically visible as it establishes our C++
ABI policy, and is thus
important beyond the scope of the case it applies to.
I'm lazy busy, so
ve left the rest of the case materials closed, though
I
Oops, didn't see the other thread where you said next resync until later,
sorry.
This message posted from opensolaris.org
Glenn Fowler gsf at research.att.com wrote:
On Tue, 11 Mar 2008 09:41:28 -0400 James Carlson
wrote:
Darren J Moffat writes:
We do have /usr/include/ast though.
Unless it's really reasonable and expected for
third parties to link
against libast, I think that's very likely to
Roland Mainz wrote:
Darren:
1. Are the changes Ok for you ? If yes I'll post
a diff for the ARC
case+manpages...
Yes that is fine.
2. Are there any CDDL or Sun-owned versions of the
optimized MD5/SHA*
functions (I'm asking since the ksh93-integration
project has the
permission
I agree that frequent updates to capture new formats
are something we
should strive for. Such a simple single source
program could be a good
test case to clear some crud out of the plumbing of
Sun's processes and
speed things up.
But I'm not convinced frequent updates absolutely
I agree that ufraw would be good to add in the
future. Ufraw uses dcraw
internally. Since dcraw isn't a shared library,
ufraw has to compile in
new versions of the dcraw source code. It might be
nice to fix that so
we don't end up maintaining both the dcraw embedded
within ufraw and the
The architecture I have no issues with. The
terminology I have serious
issues with.
Workstation could to some people imply a difference
between laptop,
desktop, workstation, server. Best not to use that
term since what
type of hardware the machine is or what function
it servers
[...]
constraints. So I think it's really to do with
supplementary additions or
subtractions (at least at login time, if not even
more dynamically) to the
normal permissions an account has, based on criteria
including but not
necessarily limited to being logged in at the
console. I don't
What about SCHED_SPORADIC? I have seen people ask about the
availability of that in the past...
This message posted from opensolaris.org
Roy T. Fielding wrote:
BTW, Joseph, veto power is defined by the OS.o
constitution and is
almost identical to that used by Apache.
BTW 1: Please point me at this (It must be somewhere
on OpenSolaris.com,
but I can't seem to find it.)
Which approach would be more robust (reporting an error, but not hanging) in
the face
of a defective interface or card; or does it make a difference? (and if it
doesn't, I suspect
most would agree that simpler is likely to be better)
This message posted from opensolaris.org
praks wrote:
James Carlson wrote:
Bart Smaalders writes:
James Carlson wrote:
Bart Smaalders writes:
It is possible to disable support for any of
these event notification
mechanism by setting the relevant environment
variable. This is
documented in the man
There are some comments in the commentary below that
I believe are worthwhile for this ARC to read and
consider
as it reviews future cases.
Darren
Original Message
Subject: Re: [sysadmin-discuss] Brussels project
announcement and
request for feedback
Date:
I am sponsoring this fasttrack for myself, and have
set the timeout to
Thursday, Sept. 13. It requests a patch release
binding.
This project enhances the X server to allow the
MIT-SHM extension to operate
between clients in non-global zones and the X server
in the global zone.
[...]
On Mon, 2007-09-03 at 06:28 -0700, Darren J Moffat
wrote:
I'm sponsoring this OpenSolaris case for Chris
Gerhard. It has some possible
standards impact but I believe based on previous
discussions this should
be acceptable, if it wasn't for the standards
impact this would likely have
[...]
ourselves. I also care
about Apple because the presence of our technology on
their platform
greatly expands the community for that particular
technology. Do I want
DTrace on my phone? You bet -- and at the moment,
Apple's looking like
the most likely vector to get us there...
Any
oops...don't know how that cc: got on there...sorry...
This message posted from opensolaris.org
Ok, fine. Then throw whatever non-conflicting commands you like
into /usr/bin and call it serendipitous discovery.
But also create a /usr/sun or whatever and populate it with
symlinks only to commands that don't come from external open source (or
have historically diverged significantly from
On Tue, Jan 30, 2007 at 05:29:16PM -0800, Richard L.
Hamilton wrote:
Ok, fine. Then throw whatever non-conflicting
commands you like
into /usr/bin and call it serendipitous discovery.
But also create a /usr/sun or whatever and populate
it with
symlinks only to commands that don't
[...]
I guess I'll just have to put the network path
first, and then invest in
HA-NFS.
You had to do the latter anyways.
Or disconnected cachefs. Or just rsync the stuff out
to the individual machines. Or ...
This message posted from opensolaris.org
[...]
As an OpenGL architecture is already provided for
SPARC by the SPARC
Graphics group, Mesa will not be delivered with Xorg
on SPARC.
[...]
Does this mean that real OpenGL will be supported by Xorg on SPARC?
(and if that can be done, why can't Xorg on SPARC also tie into the DPS
[...]
IMO vi is not an
option (unless you want to punish beginners to
learn vi before they
can use something in the shell... =:-) ), leaving
only emacs and
gmacs as options (unless you want to drive more
users into bash's
direction...).
You failed to list one choice: none. As per
Since dtksh isn't open source (until some group of people
persuade the Open Group folks to Do The Right Thing and
open CDE :-) ), how can non-Sun people work on it, short
of shelling out major $$ for a CDE source license?
This message posted from opensolaris.org
What version? In
http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libcmd/common/deflt.c
I don't see any non-static (global) functions that are other than def*; and if
I'm reading the Makefiles correctly, that's the only source file left for that
library.
ISTR some prior discussion
69 matches
Mail list logo
