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 a
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 provi
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 p
Chris Adams wrote:
> Once upon a time, Josh Boyer 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 thi
On Thu, Oct 17, 2013 at 5:54 PM, Matthew Miller
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 "random collection
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 h
Once upon a time, Josh Boyer 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 should be killed. Havi
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 r
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 unprel
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 helpfu
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
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 entirely
2013/10/17 Josh Boyer
> On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters 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
On Thu, Oct 17, 2013 at 07:28:07AM -0700, Josh Boyer wrote:
> On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters 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 d
On Thu, 17 Oct 2013 16:28:07 +0200, Josh Boyer wrote:
> On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters 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 pi
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters 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 person
> active
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 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 wor
it play more nicely
> with these integrity systems, but since it doesn't, the more rational
> approach is have it go away.
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 f
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 af
On 10/15/2013 11:52 AM, Jan Kratochvil wrote:
> 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 usef
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 ☁☁☁
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
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 in
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 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 ... qu
current known issues:
> 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?
the real q
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 u
On Wed, Oct 16, 2013 at 9:44 AM, Jan Kratochvil
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 unprelink:
> https://b
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
ted the current known issues:
> 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
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]
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 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];d
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 bo
On 10/16/2013 10:17 AM, Dridi Boukelmoune wrote:
On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen
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
p
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) 2>&1|grep ^real|tee -a
/tmp/times
without prelink:
6.220s 6.212
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 s
On Wed, Oct 16, 2013 at 7:45 AM, Jan Kratochvil
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 a known prelink B
On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen
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. But this tim
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 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 Tue, Oct 15, 2013 at 11:31 PM, Matthew Miller
wrote:
> On Tue, Oct 15, 2013 at 10:51:18PM +0100, Dridi Boukelmoune wrote:
>> $ rpm -V varnish
>> S.5T. c /etc/varnish/varnish.params
>> $ rpm -V firefox
>> $ rpm -V libreoffice-core
>> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies,
On Tue, 2013-10-15 at 20:24 +0200, Reindl Harald wrote:
> Am 15.10.2013 20:07, schrieb Jan Kratochvil:
> > On Tue, 15 Oct 2013 19:54:15 +0200, Reindl Harald wrote:
> >> there are people wich shut down or suspend machines when they are not in
> >> use
> >> how do you imagine the cronjob run while t
On Tue, Oct 15, 2013 at 10:51:18PM +0100, Dridi Boukelmoune wrote:
> $ rpm -V varnish
> S.5T. c /etc/varnish/varnish.params
> $ rpm -V firefox
> $ rpm -V libreoffice-core
> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1
Check out "-y" in the prelink man page. It does
Am 15.10.2013 23:35, schrieb drago01:
> On Tue, Oct 15, 2013 at 10:27 PM, Reindl Harald
> 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 said:
> It depends, for example in this case prelink s
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, and I work with production-like systems (and in som
On Tue, Oct 15, 2013 at 10:27 PM, Reindl Harald 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 said:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;
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 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
>>> &>/
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
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 develop
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 arg
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
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-case
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 i
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 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 10/15/2013 09:10 PM, Chris Adams wrote:
Once upon a time, Jan Kratochvil 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
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
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.
Disable/unin
-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 develope
On 10/15/2013 07:20 PM, Chris Adams wrote:
Once upon a time, "Jóhann B. Guðmundsson" 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.
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 wel
Hello,
On Tue, Oct 15, 2013 at 2:19 PM, Dhiru Kholia 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 validation of these
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 displace
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-o
Once upon a time, "Jóhann B. Guðmundsson" 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 install, support
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
>
> wh
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.
Am 15.10.2013 20:54, schrieb Chris Adams:
> Once upon a time, Jan Kratochvil 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
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
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 finge
Once upon a time, Jan Kratochvil 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 reasonable unit of
time (o
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 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. The message that started
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 comparis
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
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 p
Am 15.10.2013 19:54, schrieb Chris Adams:
> Once upon a time, Jan Kratochvil 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" ou
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 m
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 s
Am 15.10.2013 20:04, schrieb Miloslav Trmač:
> On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce 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 preli
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 foot-
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
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
On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce 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
https://lists.fedoraproject.org/pipermail/devel
On Tue, Oct 15, 2013 at 10:56 AM, 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 thr
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 prelin
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 n
Once upon a time, Jan Kratochvil 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
>
> Sorry I do not see
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
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 cy
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 negli
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
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.
>
> Tha
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 Kholia
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
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 backgro
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, 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, 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.
>
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
1 - 100 of 106 matches
Mail list logo
