On Mon, 3 Apr 2006, David Powell wrote:
> Anything in particular? There's probably not a lot we can do if
> they're the SMC technology itself, but if they're related to the
> underlying Solaris configuration someone might be able to at least
> give you some starting points.
Most of things
On Thu, Mar 30, 2006 at 04:24:39PM -0500, Bill Rushmore wrote:
> On Thu, 30 Mar 2006, David Powell wrote:
>
> > Though not SMC, the Visual Panels project is attempting to do just
> > that. (Actually, if services are all you're interested in, it
> > already does do that and is attempting to
Darren J Moffat wrote:
UNIX admin wrote:
Agreed. SMC sucks dead bunnies through a bent straw sideways; but then
again, being a hardcore shell guy, perhaps I'm the wrong person to
write that.
/usr/sadm/bin/sm* is the CLI interface to SMC.
What can we do (other than the performance issue) t
> I wonder about zipping an image of an installed
> filesystem, then copy (as in cat image | gzip -d | dd
> of=/dev/dsk/rdsk/...) that onto the drive (or pool,
> if plausible). It would be faster than writing the
> 1000's files individually. You still need package
> technology but you could get mos
I wonder about zipping an image of an installed filesystem, then copy (as in
cat image | gzip -d | dd of=/dev/dsk/rdsk/...) that onto the drive (or pool, if
plausible). It would be faster than writing the 1000's files individually. You
still need package technology but you could get most of the
David Powell wrote:
Visual Panels is written in Java, and we're quite happy with the
performance we're getting. Java performance has improved a lot, and
that's not just because computers are getting faster. I also think
it's fair to say that most of SMC's sluggishness has little to do
Peter Tribble <[EMAIL PROTECTED]> wrote:
> Not really. The fastest systems today can't saturate a DVD, 100M
> network, or hard
> disk with bzip2.
>
> I would happily exchange the 5% loss in compression for the 10x
> performance win.
>
> If you need that 5%, then there are probably other ways to ge
Rainer Orth wrote:
> Speaking of Kerberos: what are the current plans to expose the Krb5 API in
> Solaris (beyond referring to GSS-API)? While GSS-API is fine for a couple
> of applications that support it, others still need access to the `raw' Krb5
> API. Examples are the authorization related c
David Powell wrote:
>On Fri, Mar 31, 2006 at 07:56:38AM +1200, Ian Collins wrote:
>
>
>>A simple GUI interface would be a start, even a graphical overview of
>>the services would help.
>>
>>
>
> Though not SMC, the Visual Panels project is attempting to do just
> that. (Actually, if servi
On Thu, 30 Mar 2006, David Powell wrote:
> Though not SMC, the Visual Panels project is attempting to do just
> that. (Actually, if services are all you're interested in, it
> already does do that and is attempting to do a lot more.)
Will Visual Panels be the replacement for smc in future
On Fri, Mar 31, 2006 at 07:56:38AM +1200, Ian Collins wrote:
> A simple GUI interface would be a start, even a graphical overview of
> the services would help.
Though not SMC, the Visual Panels project is attempting to do just
that. (Actually, if services are all you're interested in, it
al
Ian Collins <[EMAIL PROTECTED]> wrote:
> My understanding is that 16x is the physical limit, before the disks fly
> apart!
18x is the limit.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work)
[EMAIL PROTECTED] wrote:
>>I would strongly discourage switching from bzip2. bzip2 may be "slow", but
>>CPUs will only get fast
>>
>>
>er, and meanwhile, the compression algorithm of bzip2 will stay the same.
>
>If DVD drives do not get faster, CPUs will need to get around 10x
>faster for bzi
Darren J Moffat wrote:
> UNIX admin wrote:
>
>>
>> Agreed. SMC sucks dead bunnies through a bent straw sideways; but
>> then again, being a hardcore shell guy, perhaps I'm the wrong person
>> to write that.
>
>
>
> /usr/sadm/bin/sm* is the CLI interface to SMC.
>
> What can we do (other than the p
On Thu, 30 Mar 2006, a b wrote:
> Correct. And us usual, Rich hits the nail right on the head, and I have to
> agree with him :-)
Gee thanks. :-)
> So I completely agree with Rich and understand what he's going through.
> Didn't Dennis also blog about a similar situation? "Daddy is too senior.
Bill Rushmore <[EMAIL PROTECTED]> writes:
> On Thu, 30 Mar 2006, Darren J Moffat wrote:
>
> >
> > /usr/sadm/bin/sm* is the CLI interface to SMC.
> >
> > What can we do (other than the performance issue) to improve SMC so that
> > "hardcore CLI junkies" and "pointy clickies" would both like it ?
>
> /usr/sadm/bin/sm* is the CLI interface to SMC.
>
> What can we do (other than the performance issue) to improve
> SMC so that "hardcore CLI junkies" and "pointy clickies"
> would both like it ?
I would REALLY appreciate something like "sam" in HP-UX (which is curses and
X) or yast2 in SuSE (a
On Thu, 30 Mar 2006, Darren J Moffat wrote:
>
> /usr/sadm/bin/sm* is the CLI interface to SMC.
>
> What can we do (other than the performance issue) to improve SMC so that
> "hardcore CLI junkies" and "pointy clickies" would both like it ?
Here are a few:
1. Don't make me re-enter the root passw
UNIX admin wrote:
Agreed. SMC sucks dead bunnies through a bent straw sideways; but then again,
being a hardcore shell guy, perhaps I'm the wrong person to write that.
/usr/sadm/bin/sm* is the CLI interface to SMC.
What can we do (other than the performance issue) to improve SMC so that
"h
On Thu, 30 Mar 2006, Stephen Potter wrote:
> > You're only supposed to go through installing from
> > CD/DVD once, then create a Flash(TM) archive and
> > install from the network afterwards.
>
> That's great for those of us in a networked, enterprise environment. For Joe
> R. User installing on
>Not really. The fastest systems today can't saturate a DVD, 100M
>network, or hard disk with bzip2.
Indeed. (To quickly populate workspaces I keep a weekly tar.gz of
opensolaris; a fast system can gunzip this at 10MB/s easily when
unzipping to /tmp; +/- 12s of CPU to uncompress a 230MB file to
On Thu, 2006-03-30 at 12:32, UNIX admin wrote:
> I would strongly discourage switching from bzip2. bzip2 may be "slow", but
> CPUs will only get faster, and meanwhile, the compression algorithm of bzip2
> will stay the same.
>
> When one factors in that no other cruncher/compressor/packer/archiv
Hmmm, it's a tough issue ... here is a scenario:
Let's take a regular Solaris administrator thats been doing his job for several
years now (medium to large org)... looking after 5 x V880's running Oracle 9i
on some EMC storage.
VAR: Solaris 10 GA !! OMG !! *gasp*
ADMIN: Hmmm, send me some info
> You're only supposed to go through installing from
> CD/DVD once, then create a Flash(TM) archive and
> install from the network afterwards.
That's great for those of us in a networked, enterprise environment. For Joe
R. User installing on his home PC, that's not really an option.
> I have sy
>I would strongly discourage switching from bzip2. bzip2 may be "slow", but
>CPUs will only get fast
er, and meanwhile, the compression algorithm of bzip2 will stay the same.
If DVD drives do not get faster, CPUs will need to get around 10x
faster for bzip2 to catch up with DVDs; that is, if DVD
> Yes a flash/jumpstart/whatever install would have been much
> quicker, but how
> many people are going to do that the first go-around
> with Solaris?
Well, Your average Joe User won't, that's for sure; but then again, neither
will he nor most of Linux fanboys use "KickStart" either.
On the oth
> Seconded. I really love Solaris (now... I've seen the
> light!) - but forget
> doing DVD installs. I can literally *hear* the drive
> spinning up and down
> repeatedly. I have no problem when transferring
> contiguous files from the
> dvd once Solaris is installed, it is almost certainly
> someth
> We know of several ways to speed up install, and it
> will
> happen.
>
> We need to:
>
> 1) keep dvd spun up.
> 2) switch to lower cost compression instead of bzip2
I would strongly discourage switching from bzip2. bzip2 may be "slow", but CPUs
will only get faster, and meanwhile, the compres
I think you're missing the point. I'd say most of that 95% percent isn't
used through difficulty, but through ignorance. For example, I'd say thay
95% of M$ Word's features are unused, but I don't see people claiming that
it is hard to use.
Correct. And us usual, Rich hits the nail right on t
That is not a good thing, I do agree, but at the same time - I'd say it's
Solaris that needs to improve in this regard. If people can't use your
product properly (95% of the time to use your statistic) then something is
wrong with the usability of your product. Not the (95%) of people. Not
saying
> Thanks maierkom for going where only the bold can be
> found ;)
>
;-)
I like to step forward, when I think I am not alone with my unpopular opinion.
But as I know that most people are very sensible and hoped that some at least
might know that I am a strong Solaris supporter (from
comp.unix.s
On Wed, 29 Mar 2006, Rich Teer wrote:
> Try living where I do--and yes, I do know Solaris well. :-( On more than
> one occassion, I've actually been told that I'm over qualified!
>
I can see it now:
Interviewer: "So Rich, how much do you know about Solaris systems
programming?"
> On Wed, 29 Mar 2006, David J. Orman wrote:
> I think you're missing the point. I'd say most of that 95% percent isn't
> used through difficulty, but through ignorance. For example, I'd say thay
> 95% of M$ Word's features are unused, but I don't see people claiming that
> it is hard to use.
N
On Wed, 29 Mar 2006, David J. Orman wrote:
> That is not a good thing, I do agree, but at the same time - I'd say it's
> Solaris that needs to improve in this regard. If people can't use your
> product properly (95% of the time to use your statistic) then something is
> wrong with the usability of
> This is very true, but I question what you meant by that.
>
> In my own experience, 95% of the people don't use a lot of the features of
> Solaris because they're almost completely incompetent when it comes to
> Solaris.
That is not a good thing, I do agree, but at the same time - I'd say it's
S
> 95% of the people out there doesn't use nearly all of
> the features contained in Solaris 10+ and as such
> form their opinion on the basic interface to the OS.
This is very true, but I question what you meant by that.
In my own experience, 95% of the people don't use a lot of the features of
Dne středa 29 březen 2006 15:10 Thomas Maier-Komor napsal(a):
> Yesterday, I tried to copy data to an USB stick (documented two issues
> concerning this in the bugs mailing list). During this I did an "iostat
> -xzn 5" and got about 700k/s on an USB2 stick that easily can deliver
> multimegabyte tr
> right now, I can outline what I did yesterday. If you
> want more detail, just ask and I'll provide precise
> data.
Yes, more details please.
SPARC or x86? What kind of chipset is used for the
USB host controller? The USB host controller has USB2
support, correct?
> Yesterday, I tried to cop
Thomas Maier-Komor <[EMAIL PROTECTED]> wrote:
> right now, I can outline what I did yesterday. If you want more detail, just
> ask and I'll provide precise data.
>
> Yesterday, I tried to copy data to an USB stick (documented two issues
> concerning this in the bugs mailing list). During this I
Thanks maierkom for going where only the bold can be found ;)
I agree with you 100% from a Sun VAR perspective, where we are in contact with
end-users (admins) and clients all the time.
95% of the people out there doesn't use nearly all of the features contained in
Solaris 10+ and as such form
How was the UBS stick mounted? What was the USB device detected
as? What USB controller hardware do you have?
This almost sounds like USB 1.x speeds which leads me to
suspect it's a controller issue.
Casper
___
opensolaris-discuss mailing list
open
right now, I can outline what I did yesterday. If you want more detail, just
ask and I'll provide precise data.
Yesterday, I tried to copy data to an USB stick (documented two issues
concerning this in the bugs mailing list). During this I did an "iostat -xzn 5"
and got about 700k/s on an USB2
> - USB performance (very slow, I raised an RFE some time ago)
Can you provide some test case that shows bad USB performance?
HW details? Are you running a recent opensolaris build (>= snv_35,
the one including the fix for bug 6372009)?
This message posted from opensolaris.org
___
43 matches
Mail list logo