On 03/ 1/10 07:19 PM, Scott Rotondo wrote:
Alan Coopersmith wrote:
Richard L. Hamilton wrote:
[...]
Except that pkg uses elfcmp/wsdiff type mechanisms to
not rev ELF binaries
that don't differ in the important bits, but only
differ in the timestamps
or other metadata.
[...]
Are there standal
Alan Coopersmith wrote:
Richard L. Hamilton wrote:
[...]
Except that pkg uses elfcmp/wsdiff type mechanisms to
not rev ELF binaries
that don't differ in the important bits, but only
differ in the timestamps
or other metadata.
[...]
Are there standalone tools like that, able to ignore trivial
On 03/ 1/10 03:20 AM, casper@sun.com wrote:
...
For example, on my system, when I did an image-update from build 110 to
build 111, with all of the data to be installed downloaded already, it
only took about five minutes to upgrade 666 packages and move around 480
megabytes worth of data. T
On 03/ 1/10 03:22 AM, casper@sun.com wrote:
...
It only *looks* like it downloads everything again -- this is purely a
misleading display issue that we're hoping to improve at a future point.
It did take a reasonable amount of time. Not less than downloading the
first time, but I can't be
Richard L. Hamilton wrote:
> [...]
>> Except that pkg uses elfcmp/wsdiff type mechanisms to
>> not rev ELF binaries
>> that don't differ in the important bits, but only
>> differ in the timestamps
>> or other metadata.
> [...]
>
> Are there standalone tools like that, able to ignore trivial differ
[...]
> Except that pkg uses elfcmp/wsdiff type mechanisms to
> not rev ELF binaries
> that don't differ in the important bits, but only
> differ in the timestamps
> or other metadata.
[...]
Are there standalone tools like that, able to ignore trivial differences
when comparing ELF binaries? The
>It only *looks* like it downloads everything again -- this is purely a
>misleading display issue that we're hoping to improve at a future point.
It did take a reasonable amount of time. Not less than downloading the
first time, but I can't be sure. The ips server is local, though.
>What ha
>
>
>>For example, on my system, when I did an image-update from build 110 to
>>build 111, with all of the data to be installed downloaded already, it
>>only took about five minutes to upgrade 666 packages and move around 480
>>megabytes worth of data. That's not too shabby if you ask me.
>
>Co
On 03/ 1/10 01:51 AM, casper@sun.com wrote:
...
I think you're confused about what I've said here. And no, the data is
intentionally stored by digest and not by its original name. It would
neither be practical, nor efficient to store the files in the repository
by their delivered name. The
On 03/ 1/10 01:51 AM, casper@sun.com wrote:
For example, on my system, when I did an image-update from build 110 to
build 111, with all of the data to be installed downloaded already, it
only took about five minutes to upgrade 666 packages and move around 480
megabytes worth of data. That'
>For example, on my system, when I did an image-update from build 110 to
>build 111, with all of the data to be installed downloaded already, it
>only took about five minutes to upgrade 666 packages and move around 480
>megabytes worth of data. That's not too shabby if you ask me.
Compare upg
On 02/28/10 03:22 PM, Shawn Walker wrote:
On 02/28/10 03:01 PM, casper@sun.com wrote:
...
E.g., I have broken "python" and now I need to copy the data from
the server. Where is it?
If python wasn't broken, you'd use "pkg fix" to fix it. If python was
unavailable, you'd go to the BUI for t
On 02/28/10 03:01 PM, casper@sun.com wrote:
* efficient update operations
-- Because pkg(5) only retrieves the files that have changed between
package versions between updates, the client only downloads exactly
what it needs to perform update operations. Other systems have chosen
to i
casper@sun.com wrote:
>>> * efficient update operations
>>>
>>> -- Because pkg(5) only retrieves the files that have changed between
>>> package versions between updates, the client only downloads exactly
>>> what it needs to perform update operations. Other systems have chosen
>>> to imp
>> * efficient update operations
>>
>> -- Because pkg(5) only retrieves the files that have changed between
>> package versions between updates, the client only downloads exactly
>> what it needs to perform update operations. Other systems have chosen
>> to implement this by pre-generating
On 02/28/10 06:10 AM, Shawn Walker wrote:
On 02/27/10 10:29 PM, Anon Y Mous wrote:
Ok, install OpenSolaris on a server, create a zone, and then in your
first zone just running this very basic IPS command:
pkg install SUNWman
takes forever because it downloads each man page file individual
On 02/27/10 10:29 PM, Anon Y Mous wrote:
Ok, install OpenSolaris on a server, create a zone, and then in your first zone
just running this very basic IPS command:
pkg install SUNWman
takes forever because it downloads each man page file individually. Downloading
a large number of small fi
Ok, install OpenSolaris on a server, create a zone, and then in your first zone
just running this very basic IPS command:
pkg install SUNWman
takes forever because it downloads each man page file individually. Downloading
a large number of small files via FTP or whatever will always be slowe
On 02/27/10 02:24 PM, Jürgen Keil wrote:
Has pkg been always that slow?
I suspect that pkg has been reasonably fast for the
first few packages that you installed, but has
become slower and slower the more packages
have been installed?
Hello Mr. Keil: If you suspect a standard bin/pkg to run ^
> As a matter of fact I had also thunderbird+firefox so the memory usage
> was a bit high. I just retried it now without any other "heavy app"
> other than X+gnome, and it went much much faster (7-8mn)
Since b132 there is a java vm process running on the gnome desktop.
It displays an icon in the
> > Has pkg been always that slow?
> >
> > I suspect that pkg has been reasonably fast for the
> > first few packages that you installed, but has
> > become slower and slower the more packages
> > have been installed?
>
> Hello Mr. Keil: If you suspect a standard bin/pkg to run ^reasonably
> fast
On 02/27/10 11:39 AM, Martin Bochnig wrote:
...
Package management meta-tools: survey and state of the art
http://www.mancoosi.org/edos/manager/
Which is from a survey dated March 2006. I would note though that the
results of this survey have been considered during pkg(5) implementation.
Ch
On Sat, Feb 27, 2010 at 7:47 PM, Shawn Walker wrote:
> On 02/27/10 05:54 AM, casper@sun.com wrote:
>>
>>> On Sat, Feb 27, 2010 at 12:48 PM, wrote:
> well the whole install took 2 hours
> for 1 pkg !!
> it seems that disk read/write here is the bottleneck (?).
> iostat -D
On 02/27/10 05:57 PM, Jürgen Keil wrote:
I suspect that pkg has been reasonably fast for the
first few packages that you installed, but has
become slower and slower the more packages
have been installed?
Not that much packages installed after fress install
That is, on your fresh
On 02/27/10 05:54 AM, casper@sun.com wrote:
On Sat, Feb 27, 2010 at 12:48 PM, wrote:
well the whole install took 2 hours
for 1 pkg !!
it seems that disk read/write here is the bottleneck (?).
iostat -D 2 shows my hd busy at around 100%
iosnoop reports a lot of access by pkg :
How much
On Sat, Feb 27, 2010 at 4:50 PM, Jürgen Keil wrote:
>> I ran pkg install with truss, in the hope of
>> discovering why it takes so long to complete,
>> especially AFTER it has reported that every thing is installed.
>
> You are running a fresh install of b133, correct?
>
> Has pkg been always that
> BTW when did pkg switch to python 2.6 ?
It has been using python 2.6 for several builds now.
I have an old b129 installation and that is using
python 2.6 for /usr/bin/pkg.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing li
On 02/27/10 04:09 PM, Jürgen Keil wrote:
# tail pkg.log
1.7255schedctl() = 0xFEC69000
0.0002 sigaction(SIGINT, 0x08047650, 0x080476D0) = 0
421.4744open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/messages.mo",
O_RDONLY) Err#2 ENOENT
On 02/27/10 04:09 PM, Jürgen Keil wrote:
# tail pkg.log
1.7255schedctl() = 0xFEC69000
0.0002 sigaction(SIGINT, 0x08047650, 0x080476D0) = 0
421.4744open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/messages.mo",
O_RDONLY) Err#2 ENOENT
On 02/27/10 05:31 PM, Rich Burridge wrote:
Bruno Damour wrote:
well the whole install took 2 hours
for 1 pkg !!
it seems that disk read/write here is the bottleneck (?).
Maybe you are seeing the effects of:
http://defect.opensolaris.org/bz/show_bug.cgi?id=14507
In other words, you installed
> > I suspect that pkg has been reasonably fast for the
> > first few packages that you installed, but has
> > become slower and slower the more packages
> > have been installed?
> >
> Not that much packages installed after fress install
That is, on your fresh b133 install from livecd, the
first p
On 02/27/10 03:50 PM, Jürgen Keil wrote:
I ran pkg install with truss, in the hope of
discovering why it takes so long to complete,
especially AFTER it has reported that every thing is installed.
You are running a fresh install of b133, correct?
yes, install from livecd as I couldn't
> # tail pkg.log
> 1.7255 schedctl() = 0xFEC69000
> 0.0002sigaction(SIGINT, 0x08047650, 0x080476D0) = 0
> 421.4744 open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/messages.mo",
> O_RDONLY) Err#2 ENOENT
stack backtrace for the pkg proce
> I ran pkg install with truss, in the hope of
> discovering why it takes so long to complete,
> especially AFTER it has reported that every thing is installed.
You are running a fresh install of b133, correct?
Has pkg been always that slow?
I suspect that pkg has been reasonably fast for the
fi
>On Sat, Feb 27, 2010 at 12:48 PM, wrote:
>>
>>>well the whole install took 2 hours
>>>for 1 pkg !!
>>>it seems that disk read/write here is the bottleneck (?).
>>>iostat -D 2 shows my hd busy at around 100%
>>>iosnoop reports a lot of access by pkg :
>>
>> How much memory? =A0It is possible tha
On Sat, Feb 27, 2010 at 1:19 PM, Bruno Damour wrote:
> Ok I have ONLY 1G mem, not much nowadays but anyway.
> This laptop has been tested on different systems, first of all it runs WinXP
> (at work) but I have also run gentoo (from stage 1 !, all self-compiled) and
> I never felt it unresponsive
Ok I have ONLY 1G mem, not much nowadays but anyway.
This laptop has been tested on different systems, first of all it runs WinXP
(at work) but I have also run gentoo (from stage 1 !, all self-compiled) and I
never felt it unresponsive or slow.
even running emerge -uD world was OK compared to wh
On Sat, Feb 27, 2010 at 12:48 PM, wrote:
>
>>well the whole install took 2 hours
>>for 1 pkg !!
>>it seems that disk read/write here is the bottleneck (?).
>>iostat -D 2 shows my hd busy at around 100%
>>iosnoop reports a lot of access by pkg :
>
> How much memory? It is possible that you're pag
No hope for IPS.
It kills OpenSolaris´s future.
This is not an attack.
Just a sad finding.
Yes, I bring this to the table again.
But let´s face it, what is better? A convenient slimer or an
inconvenient person who reports the truth at least once per year?
A mistake is only then a mistake, if it
>well the whole install took 2 hours
>for 1 pkg !!
>it seems that disk read/write here is the bottleneck (?).
>iostat -D 2 shows my hd busy at around 100%
>iosnoop reports a lot of access by pkg :
How much memory? It is possible that you're paging to death.
Casper
_
Hi,
Performance was also pretty terrible on my old Core 2 Quad with 4GB RAM.
That was one of the main reasons I switched to Nexenta (http://nexenta.org).
Andy
On 27 February 2010 10:52, Bruno Damour wrote:
> well the whole install took 2 hours
> for 1 pkg !!
> it seems that disk read/write her
well the whole install took 2 hours
for 1 pkg !!
it seems that disk read/write here is the bottleneck (?).
iostat -D 2 shows my hd busy at around 100%
iosnoop reports a lot of access by pkg :
UID PID DBLOCK SIZE COMM PATHNAME
[...]
0 1666 R 35943541 4096pkg
0 1
Hello,
I ran pkg install with truss, in the hope of discovering why it takes so long
to complete, especially AFTER it has reported that every thing is installed.
I ran into this (for me) mysterious result :
# truss -o pkg.log -D pkg install diagnostic/wireshark
43 matches
Mail list logo
