Garrett D'Amore wrote:
Dave Plauger wrote:
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in libast or use mmap(2).
This is an interesting
Garrett D'Amore wrote:
Roland Mainz wrote:
Garrett D'Amore wrote:
Dave Plauger wrote:
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in libast or
Alan Coopersmith wrote:
Garrett D'Amore wrote:
(What application would bind to Ctrl-Backspace? That's one I've never
seen before...)
Allegedly, it's common in emacs, though I've never used it in all the years
I've used xemacs.
Neither have. Although I have to admit that I
Brian Cameron schrieb:
+ /usr/bin/ck-seat-tool [--add --session-type=SESSION_TYPE
--display-type=DISPLAY_TYPE [--seat-id=SEAT_ID] [variables...]
| --delete --session-id=SESSION_ID]
- How are seat ids chosen if not explicitly specified, for example when
using
Brian Cameron schrieb:
As you probably know, the Desktop team has worked hard over the years
to make sure that GDM works well on Sun Ray. Our plan is to ensure
that the new GDM rewrite also works well on Sun Ray. That said, there
will probably be a few pains in making the transition.
Correct. The way the code works is that it calls fgetpwent() and if
/etc/passwd contains no value, then that account does not show up in the
Face Browser. So, users would need to avoid using the shorthand if they
want the user to show up in the GDM Face Browser.
If that is inappropriate, then
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in libast or use mmap(2).
This is an interesting implementation suggestion, but is outside the
scope of
Brian Cameron wrote:
Darren:
I updated the onepager for moovida, and moved the Obsolete/Removed
interfaces to a separate table that lists them as Removed Interfaces.
Is this okay, then?
That looks much clearer to me. It is now very obvious what is going on.
So this case gets my +1.
--
johansen at sun.com wrote:
[Originally sent this to Darren, but forgot to CC PSARC-ext]
I didn't get that email.
Hi Darren,
I got forwarded a pointer to this case that you filed. Thanks for
taking the time to do this.
Bob Doolittle schrieb:
Brian Cameron wrote:
What about when NIS or LDAP is in use ? Do we really want GDM attempting
to display 38,000+ accounts ?
As I explain above, this should not be an issue.
In a server-based (e.g. thin client) desktop environment, the number of
users who have ever
Brian Cameron Brian.Cameron at sun.com wrote:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
Since these users do not have valid shells specified, these would not
be shown.
A
Nicolas Williams schrieb:
On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote:
This sort of design is contrary to the way people want GDM to work
on other distros, so I am unsure if the changes needed to make it work
this way would go upstream. Most other distros want it to work
Brian Cameron wrote:
Nicolas:
On Thu, Aug 13, 2009 at 03:08:34PM -0500, Brian Cameron wrote:
I am fairly confident that a change to hardcode the list to a
configuration key would not be accepted upstream. The upstream GDM
community has
Joerg Schilling schrieb:
Brian Cameron Brian.Cameron at sun.com wrote:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
Since these users do not have valid shells specified, these would
Darren J Moffat schrieb:
I thought you were suggesting that the list of users to be shown in the
face browser be specified by GDM configuration, rather than using
heuristics to decide which users to show. The word hardcoding was
a poor word choice on my part. What I meant was:
- We want
http://www.opensolaris.org/os/community/arc/announcements/
OpenSolaris ARC Agenda
TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(215) 446-3661 (International)
ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorded.
08/18/2009
No meeting
08/19/2009
On Fri, Aug 14, 2009 at 12:04:53PM +0200, Joerg Barfurth wrote:
Nicolas Williams schrieb:
On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote:
This sort of design is contrary to the way people want GDM to work
on other distros, so I am unsure if the changes needed to make it work
On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote:
johansen at sun.com wrote:
http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat
I would recommend using the certificate directory approach instead of
creating a single file with all certificates.
This case
Garrett D'Amore wrote:
I think that it makes sense to at least *try* to move zebrasrv out of
/usr/bin. /usr/lib seems the right place for it.
Since zebrasrv has good command definition and /usr/bin is the
familiar location (ie. I'm not seeing /usr/lib being used anywhere
else). I think
On Fri, Aug 14, 2009 at 11:19:30AM -0600, Jim Walker wrote:
Garrett D'Amore wrote:
I think that it makes sense to at least *try* to move zebrasrv out of
/usr/bin. /usr/lib seems the right place for it.
Since zebrasrv has good command definition and /usr/bin is the
familiar location (ie.
Date: Fri, 14 Aug 2009 11:24:21 -0600
From: Andre Molyneux Andre.Molyneux at sun.com
Subject: Re: 2009/424 [idzebra]
Jim Walker wrote:
Garrett D'Amore wrote:
I think that it makes sense to at least *try* to move zebrasrv out of
/usr/bin. /usr/lib seems the right
Thanks again for your comments. Here is a summary of our responses since
yesterday.
Garrett D'Amore wrote:
Ivek Szczesniak wrote:
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation
Jim Walker wrote:
Garrett D'Amore wrote:
I think that it makes sense to at least *try* to move zebrasrv out of
/usr/bin. /usr/lib seems the right place for it.
Since zebrasrv has good command definition and /usr/bin is the
familiar location (ie. I'm not seeing /usr/lib being used anywhere
Andre Molyneux wrote:
Jim Walker wrote:
Garrett D'Amore wrote:
I think that it makes sense to at least *try* to move zebrasrv out of
/usr/bin. /usr/lib seems the right place for it.
Since zebrasrv has good command definition and /usr/bin is the
familiar location (ie. I'm not seeing
johansen at sun.com wrote:
On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote:
johansen at sun.com wrote:
http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat
I would recommend using the certificate directory approach instead of
creating a single file with
Hi All,
I was requested to clarify that the changes to the cfgadm_sbd man page
and section 4.1.2.3 will be moved to a new PSARC case since the code
for this PSARC case will not be putting back those changes since those
areas of code have not been touched. I'll post a pointer to the new
Yes, that is correct. We will be filing a separate PSARC case for any cfgadm
changes. Sorry for the confusion, I should have removed it when we updated the
PSARC case.
-Geeta
-Original Message-
From: Michael.Corcoran at Sun.COM [mailto:Michael.Corcoran at Sun.COM]
Sent: Friday, August
The yes was for any changes to cfgadm options. 4.1.2.3 contains the attachment
point info. Does that need a separate case also?
-Geeta
-Original Message-
From: Krishna, Geetanjali [mailto:geetanjali.krishna at intel.com]
Sent: Friday, August 14, 2009 4:01 PM
To: Michael.Corcoran at
28 matches
Mail list logo
