Am 18.10.2013 22:58, schrieb Robert Relyea:
On 10/17/2013 06:48 AM, Jan Kratochvil wrote:
rpm uses prelink -y so it already works in most cases and the rare cases can
be fixed in prelink. The problem is its maintainer Jakub has more
significant
work to do nowadays.
I use it as well,
Am 17.10.2013 15:48, schrieb Jan Kratochvil:
On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote:
prelink throws rocks at a lot of packages that have to check the
integrity of the shared libraries they are using. It provides no real
useful way of assisting in those tasks,
It provides
On 10/17/2013 06:48 AM, Jan Kratochvil wrote:
On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote:
prelink throws rocks at a lot of packages that have to check the
integrity of the shared libraries they are using. It provides no real
useful way of assisting in those tasks,
It provides
On 10/15/13 at 03:21pm, Daniel P. Berrange wrote:
On Tue, Oct 15, 2013 at 10:14:13AM -0400, Paul Wouters wrote:
Please take prelink behind the barn and shoot it. Thanks.
...
How can we have this discussion? We have had reports of numbers showing
no real gain. We know it affects ASLR
.
According to the numbers above my conclusion is different.
I agree there remains some work on prelink itself and some packages around to
make prelink relevant again for the predominant notebook market nowadays.
prelink performance gains [summary]
https://lists.fedoraproject.org
On 10/17/13 at 03:48pm, Jan Kratochvil wrote:
Here is another measurement. I do not agree with the initial post's approach
as (1) It flushes disk cache. That has no meaning for prelink measurement, it
just adds more fuzziness to the results and it is even unreal representation
of real world
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
Workaround of that bug is one line of code, it just has not been accepted yet.
And this is the core of the problem. No one has been spending 5 minutes
on fixing prelink, yet people have described hours and days of effort wasted
because of prelink. If
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote:
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
I agree there remains some work on prelink itself and some packages around
to
make prelink relevant again
I don't mean to pick a fight with you Jan, but you are the only
On Thu, 17 Oct 2013 16:28:07 +0200, Josh Boyer wrote:
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote:
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
I agree there remains some work on prelink itself and some packages
around to make prelink relevant again
I don't
On Thu, Oct 17, 2013 at 07:28:07AM -0700, Josh Boyer wrote:
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote:
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
I agree there remains some work on prelink itself and some packages around
to
make prelink relevant again
I
2013/10/17 Josh Boyer jwbo...@fedoraproject.org
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote:
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
I agree there remains some work on prelink itself and some packages
around
to
make prelink relevant again
I don't
On Thu, 17 Oct 2013, Daniel P. Berrange wrote:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to absolutes isn't helpful.
Agreed, there's no reason to kill it
On Thu, Oct 17, 2013 at 10:54:44AM -0400, Paul Wouters wrote:
On Thu, 17 Oct 2013, Daniel P. Berrange wrote:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to
Hi,
On 10/17/2013 04:54 PM, Paul Wouters wrote:
On Thu, 17 Oct 2013, Daniel P. Berrange wrote:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to absolutes isn't
On Thu, 17 Oct 2013, Hans de Goede wrote:
We could change the default /etc/sysconfig/prelink to default to no
prelinking, then for people with an unmodified /etc/sysconfig/prelink,
this will become the new /etc/sysconfig/prelink and the first time the
cronjob runs after the update it will
On Thu, Oct 17, 2013 at 10:54:44AM -0400, Paul Wouters wrote:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to absolutes isn't helpful.
Agreed, there's no reason to
Once upon a time, Josh Boyer jwbo...@fedoraproject.org said:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to absolutes isn't helpful.
Well, in this case, I think it
On Thu, Oct 17, 2013 at 10:36:42AM -0500, Chris Adams wrote:
Well, in this case, I think it should be killed. Having prelink in the
distribution implies that it is expected that it should, which means
that all the other packages that have to support/work-around/etc.
prelink still have to have
On Thu, Oct 17, 2013 at 5:54 PM, Matthew Miller
mat...@fedoraproject.org wrote:
If it doesn't appear to provide a significant benefit, and there's no
expectation of support (for some meaning of support), it should go
away. IMHO this is one of the differences between a distribution and
a
Chris Adams wrote:
Once upon a time, Josh Boyer jwbo...@fedoraproject.org said:
There's no reason to kill the package entirely. Some people still
want to use it despite the current issues. So just don't install it
by default. Reducing everything down to absolutes isn't helpful.
Well, in
On Tue, 15 Oct 2013 23:51:18 +0200, Dridi Boukelmoune wrote:
$ rpm -V libreoffice-core
prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1
Repeating for the third time in this thread:
This is a known prelink Bug and you can find the single line fix/workaround
there:
On 10/16/2013 12:51 AM, Dridi Boukelmoune wrote:
Hi,
This is one of these passionate threads I enjoy reading because I
usually learn something interesting, and I also enjoy people being
passionate about stuff. But this time I'm a bit disappointed about the
defaults for Fedora.
I'm a developer,
On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen
pmati...@laiskiainen.org wrote:
On 10/16/2013 12:51 AM, Dridi Boukelmoune wrote:
Hi,
This is one of these passionate threads I enjoy reading because I
usually learn something interesting, and I also enjoy people being
passionate about stuff.
On Wed, Oct 16, 2013 at 7:45 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
On Tue, 15 Oct 2013 23:51:18 +0200, Dridi Boukelmoune wrote:
$ rpm -V libreoffice-core
prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1
Repeating for the third time in this thread:
This is
On Wed, 16 Oct 2013 09:20:02 +0200, Dridi Boukelmoune wrote:
I understand, but what bothers me isn't the prelink bug but prelink
itself being installed by default (for what it does regardless of the
bug).
What exactly bothers you? It (generally) speeds up programs startup.
As a summary I see
On 10/15/2013 10:01 PM, Jan Kratochvil wrote:
I have tested a possibly real world script:
rm *;sync;(time for i in `seq 0 89`;do mplayer /dev/null -nosound -vo png
-ss $i -endpos 0 video.mp4;mv 0001.png $i.png;done) 21|grep ^real|tee -a
/tmp/times
without prelink:
6.220s 6.212s
On 10/16/2013 10:17 AM, Dridi Boukelmoune wrote:
On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen
pmati...@laiskiainen.org wrote:
On 10/16/2013 12:51 AM, Dridi Boukelmoune wrote:
Hi,
This is one of these passionate threads I enjoy reading because I
usually learn something interesting, and I
Resending since the last attempt bounced.
On Wed, Oct 16, 2013 at 03:21:31PM +0530, Siddhesh Poyarekar wrote:
On Tue, Oct 15, 2013 at 10:27:36PM +0200, Reindl Harald wrote:
Do you really run gnome-open --help 1000 times per reasonable unit of
time (or ever)? Please stop using bogus
On 10/15/2013 10:04 PM, Florian Weimer wrote:
On 10/15/2013 09:10 PM, Chris Adams wrote:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open
On Wed, 16 Oct 2013 11:56:44 +0200, Florian Weimer wrote:
So even in that totally artificial case, we gain very little,
considering the trouble that prelink is.
After all the discussion I have listed the current known issues:
prelink performance gains [summary]
https
:
prelink performance gains [summary]
https://lists.fedoraproject.org/pipermail/devel/2013-October/190309.html
While I even agree currently prelink may cause more harm than good for regular
users do you see any issue there which is not fixable?
Given how little value prelink adds, I
On Wed, 16 Oct 2013 14:45:00 +0200, Reindl Harald wrote:
why waste time and energy to fix things with little to no benefit
IIRC compiler team spends 1.5 year to get 1% of performane gain.
Here you have almost ready feature with up to ... questionable but it is in
a range of percents in some real
On Wed, Oct 16, 2013 at 9:44 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
What exactly bothers you? It (generally) speeds up programs startup.
As a summary I see prelink has some bugs:
* -y has false mismatches: https://bugzilla.redhat.com/show_bug.cgi?id=666143
* %preun does not
On Wed, 2013-10-16 at 14:58 +0200, Jan Kratochvil wrote:
On Wed, 16 Oct 2013 14:45:00 +0200, Reindl Harald wrote:
why waste time and energy to fix things with little to no benefit
IIRC compiler team spends 1.5 year to get 1% of performane gain.
Here you have almost ready feature with up to
performance gains [summary]
https://lists.fedoraproject.org/pipermail/devel/2013-October/190309.html
While I even agree currently prelink may cause more harm than good for regular
users do you see any issue there which is not fixable?
the real question remains:
why waste time and energy
Am 16.10.2013 14:58, schrieb Jan Kratochvil:
On Wed, 16 Oct 2013 14:45:00 +0200, Reindl Harald wrote:
why waste time and energy to fix things with little to no benefit
IIRC compiler team spends 1.5 year to get 1% of performane gain.
Here you have almost ready feature with up to ...
Am 16.10.2013 09:44, schrieb Jan Kratochvil:
On Wed, 16 Oct 2013 09:20:02 +0200, Dridi Boukelmoune wrote:
I understand, but what bothers me isn't the prelink bug but prelink
itself being installed by default (for what it does regardless of the
bug).
What exactly bothers you? It
Am 16.10.2013 15:20, schrieb Jan Kratochvil:
On Wed, 16 Oct 2013 15:11:13 +0200, Reindl Harald wrote:
you really do not understand the difference between faster *running*
code and some micro-seconds at *startup* of the application?
You do not understand overall system performance is
On Wed, Oct 16, 2013 at 09:57:37AM +0300, Panu Matilainen wrote:
Yup, prelink screws up rpm -V pretty badly.
To me, this line _alone_ should end the conversation.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org
--
devel mailing list
Hi,
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
- Here are some measurements (for LibreOffice [2] loading time in
seconds) done using the unSPEC benchmarking suite. These numbers
are repeatable and you are encouraged to try
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
Hi,
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
- Here are some measurements (for LibreOffice [2] loading time in
seconds) done using the unSPEC
On 10/15/13 at 05:30am, Josh Boyer wrote:
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
...
- For building kernels (using the kernel-bench [3]
On Tue, Oct 15, 2013 at 5:55 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
On 10/15/13 at 05:30am, Josh Boyer wrote:
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations
On Tue, 15 Oct 2013, Dhiru Kholia wrote:
In short, we could not distinguish the performance gains of prelink over
the background noise in many (or even most) cases.
So, I was wondering if you are aware of any use-cases where prelink
provides measurable benefits. In would be awesome if you
On Tue, Oct 15, 2013 at 10:14:13AM -0400, Paul Wouters wrote:
On Tue, 15 Oct 2013, Dhiru Kholia wrote:
In short, we could not distinguish the performance gains of prelink over
the background noise in many (or even most) cases.
So, I was wondering if you are aware of any use-cases where
On Tue, 15 Oct 2013 16:21:01 +0200, Daniel P. Berrange wrote:
To justify removing it, we just need to collect data to show that those
performance benefits no longer exist, with current hardware and software
combination in Fedora. That is what this email thread is seeking to confirm.
There is
On Tue, Oct 15, 2013 at 04:54:16PM +0200, Jan Kratochvil wrote:
To justify removing it, we just need to collect data to show that those
performance benefits no longer exist, with current hardware and software
combination in Fedora. That is what this email thread is seeking to confirm.
There
On Tue, 15 Oct 2013 16:59:59 +0200, Daniel P. Berrange wrote:
I wouldn't read that as saying that prelink is slowing down startup,
rather that the benefit of prelink is so small as to be indistinguishable
from the background noise.
That's the problem we even disagree how to read the numbers.
On Tue, 15 Oct 2013 17:04:05 +0200, Matthew Miller wrote:
But, since prelink presents other problems on its own,
Prelinked system is a good test for tools like GDB, elfutils and others they
can properly handle the displacements of sections/segments.
This is something that ELF does not forbid so
On Tue, Oct 15, 2013 at 05:11:52PM +0200, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 16:59:59 +0200, Daniel P. Berrange wrote:
I wouldn't read that as saying that prelink is slowing down startup,
rather that the benefit of prelink is so small as to be indistinguishable
from the background
On Tue, Oct 15, 2013 at 04:54:16PM +0200, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 16:21:01 +0200, Daniel P. Berrange wrote:
To justify removing it, we just need to collect data to show that those
performance benefits no longer exist, with current hardware and software
combination in
the prelink default should be banned from the distribution
because this is always the excuse not activate hardening-flags
for packages because PIE binaries are not prelinked and people
still insist it brings great performance gains which is mostly
not true
Am 15.10.2013 14:19, schrieb Dhiru
On 10/15/13 at 05:11pm, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 16:59:59 +0200, Daniel P. Berrange wrote:
I wouldn't read that as saying that prelink is slowing down startup,
rather that the benefit of prelink is so small as to be indistinguishable
from the background noise.
That's the
On Tue, 15 Oct 2013 18:27:23 +0200, Dhiru Kholia wrote:
In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.
Nobody says prelink brings _big_ gains. It is just a negligible performance
and negligible battery optimization
Am 15.10.2013 19:32, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 18:27:23 +0200, Dhiru Kholia wrote:
In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.
Nobody says prelink brings _big_ gains. It is just a negligible
On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote:
* look at the amount of updates and how they hit prelinked libraries until
prelink ran again
* look at the lsof | grep DEL | grep /usr output caused by prelink
Sorry I do not see what disadvantage is it?
* look at the wasted cycles
On Tue, 2013-10-15 at 19:32 +0200, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 18:27:23 +0200, Dhiru Kholia wrote:
In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.
Nobody says prelink brings _big_ gains. It is just
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote:
* look at the amount of updates and how they hit prelinked libraries until
prelink ran again
* look at the lsof | grep DEL | grep /usr output caused by prelink
On Tue, 15 Oct 2013 19:50:44 +0200, Simo Sorce wrote:
Many tools need to juggle the fact these binaries have been changed, and
make checkers more complex and prone to faults.
So let's build the whole system with -O0 and we can throw away most of
compilers and half of debuggers, which are all
On Tue, 15 Oct 2013 19:54:21 +0200, Chris Adams wrote:
Now you are wasting a chunk of RAM, as it can't be shared between
non-prelinked and prelinked bins/libs.
OK, yes. I believe with RAM prices and therefore RAM sizes nowadays you will
still have overall better system performance with
On Tue, Oct 15, 2013 at 10:56 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
On Tue, 15 Oct 2013 19:50:44 +0200, Simo Sorce wrote:
Many tools need to juggle the fact these binaries have been changed, and
make checkers more complex and prone to faults.
So let's build the whole system with
On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce s...@redhat.com wrote:
Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
Most of the security benefit is, AFAICS, not negated by prelink (see
On Tue, 15 Oct 2013 19:54:15 +0200, Reindl Harald wrote:
have fun in distinct between prelink caused needs-restarting or real
This is a bug of update system it does not know if an updated service needs
restarting or not.
your notebooks are running 24 hours a day?
really?
OT: Yes, really. I
On Tue, 2013-10-15 at 19:56 +0200, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 19:50:44 +0200, Simo Sorce wrote:
Many tools need to juggle the fact these binaries have been changed, and
make checkers more complex and prone to faults.
So let's build the whole system with -O0 and we can throw
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
I just do not understand why to give up on that negligible optimization when
it brings no disadvantages.
Because you did not my previous email?
- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
- FIPS
Am 15.10.2013 20:04, schrieb Miloslav Trmač:
On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce s...@redhat.com wrote:
Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
Most of the security benefit is, AFAICS, not negated
Am 15.10.2013 19:49, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote:
* look at the amount of updates and how they hit prelinked libraries until
prelink ran again
* look at the lsof | grep DEL | grep /usr output caused by prelink
Sorry I do not see what
Am 15.10.2013 19:54, schrieb Chris Adams:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote:
* look at the amount of updates and how they hit prelinked libraries until
prelink ran again
* look at the lsof | grep DEL |
Am 15.10.2013 20:07, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 19:54:15 +0200, Reindl Harald wrote:
have fun in distinct between prelink caused needs-restarting or real
This is a bug of update system it does not know if an updated service needs
restarting or not.
you can always point
Am 15.10.2013 19:56, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 19:50:44 +0200, Simo Sorce wrote:
Many tools need to juggle the fact these binaries have been changed, and
make checkers more complex and prone to faults.
So let's build the whole system with -O0 and we can throw away most of
On Tue, 15 Oct 2013 20:24:06 +0200, Reindl Harald wrote:
Am 15.10.2013 20:07, schrieb Jan Kratochvil:
This is a bug of update system it does not know if an updated service needs
restarting or not.
you can always point with your finger somewhere else
the better way is solve the root cause
On Tue, 15 Oct 2013 20:25:10 +0200, Paul Wouters wrote:
- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
You can always make your software development life more simple by giving up on
some useful feature. That -O2 vs. -O0 build is a good
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
You can always make your software development life more simple by giving up on
some useful feature. That -O2 vs. -O0 build is a good comparison.
Since you keep repeating this one: -O2 vs. -O0 has a significant
performance gain.
On Tue, 15 Oct 2013 20:54:06 +0200, Chris Adams wrote:
Since you keep repeating this one: -O2 vs. -O0 has a significant
performance gain. The message that started this thread indicates that
prelink may not have a significant gain anymore. If that's the case,
than _any_ effort is not worth
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
It depends, for example in this case prelink saves 33% of time (and battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
Do you really run gnome-open --help 1000 times per
Am 15.10.2013 20:40, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 20:24:06 +0200, Reindl Harald wrote:
Am 15.10.2013 20:07, schrieb Jan Kratochvil:
This is a bug of update system it does not know if an updated service needs
restarting or not.
you can always point with your finger somewhere
Am 15.10.2013 20:52, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 20:25:10 +0200, Paul Wouters wrote:
- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
You can always make your software development life more simple by giving up on
some useful
Am 15.10.2013 20:54, schrieb Chris Adams:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
You can always make your software development life more simple by giving up
on
some useful feature. That -O2 vs. -O0 build is a good comparison.
Since you keep repeating this one:
Am 15.10.2013 21:05, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 20:54:06 +0200, Chris Adams wrote:
Since you keep repeating this one: -O2 vs. -O0 has a significant
performance gain. The message that started this thread indicates that
prelink may not have a significant gain anymore. If
On Tue, 15 Oct 2013 21:08:40 +0200, Reindl Harald wrote:
Am 15.10.2013 21:05, schrieb Jan Kratochvil:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
where are the
Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said:
I say we should remove it from the standard comps group thus making
it optional to install for people that see some benefit in still
using it.
I'd actually suggest that prelink be an all-or-nothing. If it isn't in
the default
Am 15.10.2013 21:13, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 21:08:40 +0200, Reindl Harald wrote:
Am 15.10.2013 21:05, schrieb Jan Kratochvil:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
On Tue, Oct 15, 2013 at 05:17:28PM +0200, Jan Kratochvil wrote:
On Tue, 15 Oct 2013 17:04:05 +0200, Matthew Miller wrote:
But, since prelink presents other problems on its own,
Prelinked system is a good test for tools like GDB, elfutils and others they
can properly handle the displacements
Hello,
On Tue, Oct 15, 2013 at 2:19 PM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
- Here are some measurements (for LibreOffice [2] loading time in
seconds) done using the unSPEC benchmarking suite. These numbers
are repeatable and you are encouraged to try unSPEC to do
independent
On 10/15/2013 06:40 PM, Jan Kratochvil wrote:
Improved performance.
I'm not sure where this is coming from but it looks like people are
confusing improved performance with improved startup of applications.
And afaik it can trigger false positive with security related
applications as well
On 10/15/2013 07:20 PM, Chris Adams wrote:
Once upon a time, Jóhann B. Guðmundssonjohan...@gmail.com said:
I say we should remove it from the standard comps group thus making
it optional to install for people that see some benefit in still
using it.
I'd actually suggest that prelink be an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/15/2013 03:20 PM, Reindl Harald wrote:
Am 15.10.2013 21:13, schrieb Jan Kratochvil:
OT: I use mod_perl for majority of my web code
and why do you than defeat prelink that much? are you the developer
of it or married the developer?
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
- FIPS foot-bullets
I really do not care and do not run FIPS.
Your personal views are irrelevant. You are a package maintainer. When
other people care about FIPS, you as a package maintainer should care
about playing nicely with FIPS.
On Tue, 15 Oct 2013 21:10:34 +0200, Chris Adams wrote:
Do you really run gnome-open --help 1000 times per reasonable unit of
time (or ever)? Please stop using bogus comparisons and highly
contrived tests. They do nothing to help your argument.
The goal of this example was to show that in a
On 10/15/2013 09:10 PM, Chris Adams wrote:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
It depends, for example in this case prelink saves 33% of time (and battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
Do you
On Tue, 15 Oct 2013 21:59:13 +0200, Paul Wouters wrote:
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
Disable/uninstall prelink for FIPS.
I tried that. I submitted a patch for prelink to un-prelink on
de-install in %preun. It has been ignored by you for over a year and
I seriously had to
On Tue, Oct 15, 2013 at 09:05:03PM +0200, Jan Kratochvil wrote:
It depends, for example in this case prelink saves 33% of time (and battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
I hope we can all agree that this is not useful example.
On Tue, 15 Oct 2013 22:12:00 +0200, Matthew Miller wrote:
On Tue, Oct 15, 2013 at 09:05:03PM +0200, Jan Kratochvil wrote:
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
I hope we can all agree that this is not useful example.
Explained in:
On Tue, Oct 15, 2013 at 10:14:13AM -0400, Paul Wouters wrote:
On Tue, 15 Oct 2013, Dhiru Kholia wrote:
In short, we could not distinguish the performance gains of prelink over
the background noise in many (or even most) cases.
So, I was wondering if you are aware of any use-cases where
On Tue, Oct 15, 2013 at 02:25:10PM -0400, Paul Wouters wrote:
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
I just do not understand why to give up on that negligible optimization when
it brings no disadvantages.
Because you did not my previous email?
- complexity
- complicated prelink
Am 15.10.2013 22:01, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 21:10:34 +0200, Chris Adams wrote:
Do you really run gnome-open --help 1000 times per reasonable unit of
time (or ever)? Please stop using bogus comparisons and highly
contrived tests. They do nothing to help your argument.
Am 15.10.2013 21:55, schrieb Stephen Gallagher:
On 10/15/2013 03:20 PM, Reindl Harald wrote:
Am 15.10.2013 21:13, schrieb Jan Kratochvil:
OT: I use mod_perl for majority of my web code
and why do you than defeat prelink that much? are you the developer
of it or married the developer?
Am 15.10.2013 22:17, schrieb Jan Kratochvil:
On Tue, 15 Oct 2013 22:12:00 +0200, Matthew Miller wrote:
On Tue, Oct 15, 2013 at 09:05:03PM +0200, Jan Kratochvil wrote:
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
I hope we can all agree that
Am 15.10.2013 22:04, schrieb Florian Weimer:
On 10/15/2013 09:10 PM, Chris Adams wrote:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open
On Tue, Oct 15, 2013 at 10:27 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 15.10.2013 22:04, schrieb Florian Weimer:
On 10/15/2013 09:10 PM, Chris Adams wrote:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
It depends, for example in this case prelink saves 33% of
1 - 100 of 104 matches
Mail list logo
