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 get it
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
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
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
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
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
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 compression
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
something
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 other
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 DVDs
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
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
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/archiver
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 his
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
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)
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
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 services are all
- 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
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
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
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
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 did an
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
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
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
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?
27 matches
Mail list logo
