Re: prelink performance gains

[Panu Matilainen]

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, and I work with production-like systems (and in some
cases production systems) on my day job, so integrity of the system is
something very important to me. I was startled when I first read that
prelink touches binaries. For I'm too lazy to mount /usr as read-only
(actually too lazy to mount it read/write for each yum upgrade), I
naively expected binaries would be safe with default settings
(assuming no attack).

I've run the following commands:

$ 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

S.?../usr/lib64/libreoffice/program/gengal.bin
prelink: /tmp/#prelink#.3AZudQ: Recorded 87 dependencies, now seeing -1

S.?../usr/lib64/libreoffice/program/libavmedialo.so
prelink: /tmp/#prelink#.9xDUuT: Recorded 16 dependencies, now seeing -1

S.?../usr/lib64/libreoffice/program/libbasegfxlo.so
[...]

Obviously, I'm ok with varnish being touched, I've changed something
in the configuration. I'm also relieved that firefox's clean, because I
use it heavily on a day-to-day basis. But this is rather disturbing to
see prelink on rpm's output. Does it mean that rpm *itself* has been
touched by prelink ? This sounds critical to me, how can I know that
my rpmdb hasn't been corrupted ?


Yup, prelink screws up rpm -V pretty badly. Rpm does do know about 
prelink and does 'prelink -u' to verify the unprelinked binary matches 
the original digest but all too often prelink -u fails, in which case 
there's nothing rpm can do about it. As in the above cases and perhaps 
the more common one:


[root@localhost ~]# rpm -Va
prelink: /usr/lib/udev/udev-configure-printer: at least one of file's 
dependencies has changed since prelinking

S.?../usr/lib/udev/udev-configure-printer
.M.../var/lib/nfs/rpc_pipefs
.M.../var/log/journal
prelink: /usr/bin/eog: at least one of file's dependencies has changed 
since prelinking

S.?../usr/bin/eog
[...]

This might not be *that* much of an issue on a more stable distro, but 
given the constant churn of Fedora there's not a day when something 
hasn't changed, causing rpm -Va (and other security tools) to come up 
with indeterminate results until the prelink cronjob runs. And then more 
stuff gets updated etc...



Of course an attacker that would gain root access to the system could
probably alter the rpmdb to "hide" what changed on the filesystem, but
that's not my point.


Silently changing rpmdb to match what changed on the filesystem is that 
easy as the file digests are buried within headers guarded with digital 
signatures and further digests over the contents. You basically need to 
replace the entire package, at which point it will no longer have a 
Fedora signature and is quite a clear indication that something is not 
right.


- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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:
-y has false mismatches
https://bugzilla.redhat.com/show_bug.cgi?id=666143

The 'rpm -V' output should be also fixed by full prelink of the system:
touch /var/lib/prelink/force; /etc/cron.daily/prelink


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 20 Beta Change Freeze

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

as the Fedora 20 schedule[1] states the Beta change freeze is upon
us. As of now all Beta freeze only accepted exceptions[2] will be
allowed in. 


we are at the beta stage of release, so the Beta_to_Pre_Release[3]
stage of the updates policy applies. 

Regards

Dennis

[1] http://fedorapeople.org/groups/schedule/f-20/f-20-devel-tasks.html
[2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[3] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSXi+QAAoJEH7ltONmPFDRBPMQAKS+GiGKPRHisr0SGzXU7j9n
OkMuYe5RNnXcvGWTUJxS6JMRzOltmkipVIMdjV1GQzKUEIQnDSBQe6oZmnhDgCQj
hZTWG5PK/RT0CJc2lMMFDkmDDDM3W7BqLeH23hH7pc8rxG1nJROcyx4Nx8qLi9MX
P/n9n5A92Ej1iKavEIBvDAFvuk2zqG2k6ZHYbXiqBY3E4N45UibZM6EDA8JceOYS
Ga51yDSwzlS7UNXaSA04A9k3gnrjPqwG9qCah6TvKZCpjFt/iGfkv7UhVWpJRvZk
samtuk72gHeIDrxMRxe+V3GMP958NYZSkticYw/2LdRPKS2ncIvjoRlWesxsdAn6
23yvlIgKVyWSp9ArR8tvdiCdxStQAKvGG30uagStkKimZmUP32pJHfw2CvyUPkXi
+dZPlCyG+Mg63PQAtQQmlFo0hEIrEWRD86iKn0GTsYVT9Uob9qhKBaLg9IddNH8Z
EpNInx1P0mFBjnznRMgs5IHjrENCNikVh6K8rv3sPPg4TgniVCpsN5jYG9SUxFVB
7A1HMuGyBHUvust8Xi8hGAtOwSVJUbG3WCrO1UZebirqptRZVscy9M5X8a3rjkBp
Tdopg8lr9QCxN6/REeIS7bd8saW9lSH3aAzxckDsnNwYpHgSdVqRCSshOttGdsGl
7d3ib/ZMmAAnNX5xdKX1
=ExKR
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Dridi Boukelmoune]

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, now seeing -1
>
> Check out "-y" in the prelink man page. It does a dance where it undoes
> prelinking so the original checksum can be calculated.

Didn't work, after a quick peep in the man I ended up doing:
$ sudo prelink --undo --all

A few reboots, and I still don't notice any obvious degradation of the
start time of either the OS or programs like writer. I should have
read the man in the first place, but I was a bit upset.

>> I've removed the prelink package:
>
> There was a bug referenced earlier in this thread: removing prelink doesn't
> undo what it's already done, so this doesn't work. Instead, you have to
> configure prelink to disable itself, run it again over all of your files,
> and *then* remove.
>
>> Are there other packages installed by default that would alter my system ?
>
> Not in this way, no.

Thank you for your help, feeling much better :)

> --
> Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: boost141 and stability of Boost API?

[Dave Johansen]

On Sun, Oct 13, 2013 at 8:54 AM, Robert Scheck wrote:

> Hallo Dave,
>
> On Sat, 28 Sep 2013, Dave Johansen wrote:
> > I just noticed that the boost141 package had been previously available in
> > Fedora, but it has since been removed (
> > https://fedorahosted.org/rel-eng/ticket/5291 ). I'm not familiar with
> the
> > recent changes in Boost, but is the API stable enough to support a
> package
> > to build on EL 5/6 and Fedora?
>
> the boost141 was more by accident in Fedora. I needed the package for
> Zarafa in Fedora EPEL 4 and 5. The package is a rebuild of boost from
> RHEL 6 with adaptions to make it installable in parallel with the old
> boost versions that RHEL 4 and 5 ship.
>
> My personal goal is to keep the boost141 package in sync with RHEL 6
> one - so there should be no ABI/API changes in Fedora EPEL 5 for this
> package ever.
>
> I am also not following up this boost141 or boost148 or whatever topic
> for Fedora as Zarafa (the package why I needed this) is able to handle
> more recent boost versions now - however nothing older than boost141.
>

It seems that having the same version available in both EL 5 and 6 probably
satisfies the need, and Fedora is ok with just having the latest version,
so I guess it makes sense to not have boost141 in Fedora.
Thanks,
Dave
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Mathieu Bridon]

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 they are not in use for this
> >> *majority* of users?
> > 
> > These users really should uninstall prelink as they cannot use it
> 
> if the majority should uninstall something because they can't
> use it it must not be active in a default setup

Apparently the Desktop team agreed with you:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=bb14cdd406411755cf44bacdbb437a1396a13e86

One less thing to remove after a new install. :)


-- 
Mathieu

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Chris Murphy]

On Oct 15, 2013, at 4:29 PM, Richard W.M. Jones  wrote:

> On Tue, Oct 15, 2013 at 04:04:28PM -0600, Chris Murphy wrote:
>> I'm happy to hear it argued I should instead use the LV space for a
>> regular partition formatted ext2 and drop the qcow2 file
>> there. There's still overhead of two file systems there, but may
>> compare to LV performance.
> 
> I guess you'll have to try that and see how it works out.
> 
> However don't use ext2.  Use ext4 which supports extents and hence
> will have much lower metadata over for big files like disk images.

Fair point. The system I have, has a disk with both XFS formatted partition (no 
LVM) and LVM space on it.

Fedora 20 default BTRFS guided install to an LV takes 51 minutes. Firstboot 
systemd-analyze:
878ms (kernel) + 2.755s (initrd) + 24.796s (userspace) = 28.429s

The same install parameters to qcow2 on XFS takes 1h42m. Firstboot 
systemd-analyze:
876ms (kernel) + 3.065s (initrd) + 31.858s (userspace) = 35.799s


Boot difference is negligible, but the installation time difference is quite 
large, so it looks like write performance is where the penalty is. I'd be 
surprised if there's a significant difference with qcow2 on ext4.


Chris Murphy


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Josh Stone]

On 10/15/2013 05:15 PM, Chris Murphy wrote:
> 
> On Oct 15, 2013, at 4:30 PM, Josh Stone  wrote:
> 
>> On 10/15/2013 02:46 PM, Richard W.M. Jones wrote:
>>> On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
 The better snapshots sound ideal for VM testing. Snapshot a
 successful install and then try to break the snapshot. Etc.

 Presently virt-manager ignores thinp pools and only creates
 conventional LV's. I haven't tried using virsh to force it to use an
 already created virtualsize LV as backing, but I'm wondering if it
 should work. If not, is there a rough time frame on such support?
>>
>> FWIW, I have tried, and my VMs with thin LV storage are working fine,
>> even though the libvirt storage pool barfs on the VG.  (bz924672)
> 
> So you're using virsh to compel it to use the LV I take it?

I only just started using this, and I converted my existing VMs to this
underneath by manually creating a thin volume, copying the "thick"
volume to it, then lvrename so the thin is in place.  Libvirt didn't bat
an eye at the change.

I've since tried cloning by taking a manual LVM snapshot, then
"virt-clone ... --file=/dev/vg_foo/lv_bar --preserve-data".  This also
booted on the thin device just fine.  It would be nice if virt-clone
could do the snapshot itself though.

So I'm not sure about virsh commands, but it seems possible.  I did try
in virt-manager, you can still get to the thin volumes by using "Browse
Local" and go into /dev (assuming you are actually local).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora and ECDHE: now supported in OpenSSL

[Tom Callaway]

On 10/15/2013 05:13 PM, Paul Wouters wrote:
> On Tue, 15 Oct 2013, Reindl Harald wrote:
> 
>> since OpenSSL in Fedora from now on supports ECDHE
>> depending software needs to be rebuilt to make use
>> of it as well as libraries like NSS/GNUTLS should
>> do the same and depending packages like Firefox
>> needs a rebuild against refreshed NSS to support
>> it also on the client side
> 
> Is there an updated page about ECC in Fedora? What ECC
> curves are allowed? What implementations?

I'm working on what we can say about what is permissible. For now, if
you have a package with ECC and you want to have it enabled, just file
bugs and block them against 1019390.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Chris Murphy]

On Oct 15, 2013, at 4:30 PM, Josh Stone  wrote:

> On 10/15/2013 02:46 PM, Richard W.M. Jones wrote:
>> On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
>>> The better snapshots sound ideal for VM testing. Snapshot a
>>> successful install and then try to break the snapshot. Etc.
>>> 
>>> Presently virt-manager ignores thinp pools and only creates
>>> conventional LV's. I haven't tried using virsh to force it to use an
>>> already created virtualsize LV as backing, but I'm wondering if it
>>> should work. If not, is there a rough time frame on such support?
> 
> FWIW, I have tried, and my VMs with thin LV storage are working fine,
> even though the libvirt storage pool barfs on the VG.  (bz924672)

So you're using virsh to compel it to use the LV I take it?

> 
>> Is using LVs for this over-thinking things?
> 
> One nice aspect with thin LVM snapshots is you don't need to worry about
> preserving the chain of origin.  There's no backing file except the main
> thinpool itself.  One can snapshot to arbitrary depths, and delete old
> images anywhere, freeing the unique blocks but keeping whatever is still
> shared.

Yes, this is like btrfs snapshots. It doesn't matter whether the original or 
snapshot subvolume is destroyed, whichever subvolume remains is equally usable.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Matthew Miller]

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 a dance where it undoes
prelinking so the original checksum can be calculated.

> I've removed the prelink package:

There was a bug referenced earlier in this thread: removing prelink doesn't
undo what it's already done, so this doesn't work. Instead, you have to
configure prelink to disable itself, run it again over all of your files,
and *then* remove.

> Are there other packages installed by default that would alter my system ?

Not in this way, no.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Josh Stone]

On 10/15/2013 02:46 PM, Richard W.M. Jones wrote:
> On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
>> The better snapshots sound ideal for VM testing. Snapshot a
>> successful install and then try to break the snapshot. Etc.
>>
>> Presently virt-manager ignores thinp pools and only creates
>> conventional LV's. I haven't tried using virsh to force it to use an
>> already created virtualsize LV as backing, but I'm wondering if it
>> should work. If not, is there a rough time frame on such support?

FWIW, I have tried, and my VMs with thin LV storage are working fine,
even though the libvirt storage pool barfs on the VG.  (bz924672)

> Is using LVs for this over-thinking things?

One nice aspect with thin LVM snapshots is you don't need to worry about
preserving the chain of origin.  There's no backing file except the main
thinpool itself.  One can snapshot to arbitrary depths, and delete old
images anywhere, freeing the unique blocks but keeping whatever is still
shared.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Richard W.M. Jones]

On Tue, Oct 15, 2013 at 04:04:28PM -0600, Chris Murphy wrote:
> I'm happy to hear it argued I should instead use the LV space for a
> regular partition formatted ext2 and drop the qcow2 file
> there. There's still overhead of two file systems there, but may
> compare to LV performance.

I guess you'll have to try that and see how it works out.

However don't use ext2.  Use ext4 which supports extents and hence
will have much lower metadata over for big files like disk images.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Chris Murphy]

On Oct 15, 2013, at 3:46 PM, Richard W.M. Jones  wrote:

> On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
>> The better snapshots sound ideal for VM testing. Snapshot a
>> successful install and then try to break the snapshot. Etc.
>> 
>> Presently virt-manager ignores thinp pools and only creates
>> conventional LV's. I haven't tried using virsh to force it to use an
>> already created virtualsize LV as backing, but I'm wondering if it
>> should work. If not, is there a rough time frame on such support?
> 
> Is using LVs for this over-thinking things?

Could be.

> Creating a snapshot of a regular file which efficiently shares the
> backing disk is easy, and doesn't require root or special support:
> 
>  qemu-img create -f qcow2 -b original snapshot.qcow2

Yes but unallocated qcow2 is slower than either kind of LV. And it's noticeable 
when doing something like guest using XFS in a qcow2 file on btrfs host, or 
guest using btrfs in a qcow2 file on btrfs host. It's double the file system 
activity. On an LV there's pretty close to no hit.

I'm happy to hear it argued I should instead use the LV space for a regular 
partition formatted ext2 and drop the qcow2 file there. There's still overhead 
of two file systems there, but may compare to LV performance.

> 
> Then you can import this as a new guest in libvirt, again *without*
> needing root:
> 
>  virt-install --import --name snapshot \
>--ram 1024 --disk path=snapshot.qcow2,format=qcow2
> 
> And in Fedora 20 we'll have virt-builder, which makes creating the
> original images quick too.  (Not to mention virt-sysprep and all the
> other tools to manipulate disk images easily, without root)

Hmm good to know.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 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 (or ever)?  Please stop using bogus comparisons and highly
 contrived tests.  They do nothing to help your argument.
>>>
>>> This isn't totally invalid.  I assume that some shell scripts with tight 
>>> loops are the only thing that actually
>>> benefits from prelinking today. People write those, unfortunately.
>>
>> it is - they are *not* loading a lot of dynmaic linked libraries
>>
>> [harry@srv-rhsoft:~]$ ldd /usr/bin/bash
>> linux-vdso.so.1 =>  (0x7fffc9764000)
>> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000)
>> libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000)
> 
> Yes because shell is a real programming language that does not have to
> start tons of other binaries to do useful stuff ... oh wait

most shell scripts are not many thousand lines and calls long
the question of this thread is "are the performance gains worth"

*no* they are *not worth* as long you can't measure them without get
the same differences by starting a test often enough caused by the
typical background noise of other processes

as long as you need a idle system to measure performance gains
they are not worth the wasted time and the big applications
which in theory gain from it -> they are not started often
enough

and for the guy multiple times said "why use -O2 and not -O0":
because there is a difference between *one time* optimization
deployed to *all* users and things like prelink wasting time
and ressources on the target machine - the latter is useless



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Dridi Boukelmoune]

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 some
cases production systems) on my day job, so integrity of the system is
something very important to me. I was startled when I first read that
prelink touches binaries. For I'm too lazy to mount /usr as read-only
(actually too lazy to mount it read/write for each yum upgrade), I
naively expected binaries would be safe with default settings
(assuming no attack).

I've run the following commands:

$ 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

S.?../usr/lib64/libreoffice/program/gengal.bin
prelink: /tmp/#prelink#.3AZudQ: Recorded 87 dependencies, now seeing -1

S.?../usr/lib64/libreoffice/program/libavmedialo.so
prelink: /tmp/#prelink#.9xDUuT: Recorded 16 dependencies, now seeing -1

S.?../usr/lib64/libreoffice/program/libbasegfxlo.so
[...]

Obviously, I'm ok with varnish being touched, I've changed something
in the configuration. I'm also relieved that firefox's clean, because I
use it heavily on a day-to-day basis. But this is rather disturbing to
see prelink on rpm's output. Does it mean that rpm *itself* has been
touched by prelink ? This sounds critical to me, how can I know that
my rpmdb hasn't been corrupted ?

Of course an attacker that would gain root access to the system could
probably alter the rpmdb to "hide" what changed on the filesystem, but
that's not my point.

I've removed the prelink package:

$ rpm -V libreoffice-core
S.5../usr/lib64/libreoffice/program/gengal.bin
S.5../usr/lib64/libreoffice/program/gnome-open-url.bin
S.5../usr/lib64/libreoffice/program/libavmedialo.so
S.5../usr/lib64/libreoffice/program/libbasegfxlo.so
S.5../usr/lib64/libreoffice/program/libcanvastoolslo.so
[...]

Now libreoffice still appears to be (differently) tainted, but rpm
doesn't output prelink stuff anymore (which isn't less scary).

Don't get me wrong, I really enjoy Fedora on my laptops (and before on
VMs) but I have a serious trust issue now:
- this is part of the distribution *by default*
- it is present and already acts at the very first boot AFAIU
- removing it doesn't restore the binaries (I didn't expect it would)
- apparently it prevents hardened builds in some cases

After three reboots, I can't tell the difference between now and
before, but to be fair I haven't really paid attention to the start
time of the system and applications such as the ones in libreoffice.
In my opinion, if there is no perceived latency, it is irrelevant.

It all started as a fun thread, with interesting opinions and
arguments, but now I have one question:
Are there other packages installed by default that would alter my system ?

Best Regards,
Dridi

PS. I'm a total security noob, I'm just aware of basic stuff

On Tue, Oct 15, 2013 at 10:35 PM, drago01  wrote:
> 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;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 (or ever)?  Please stop using bogus comparisons and highly
 contrived tests.  They do nothing to help your argument.
>>>
>>> This isn't totally invalid.  I assume that some shell scripts with tight 
>>> loops are the only thing that actually
>>> benefits from prelinking today. People write those, unfortunately.
>>
>> it is - they are *not* loading a lot of dynmaic linked libraries
>>
>> [harry@srv-rhsoft:~]$ ldd /usr/bin/bash
>> linux-vdso.so.1 =>  (0x7fffc9764000)
>> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000)
>> libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000)
>
> Yes because shell is a real programming language that does not have to
> start tons of other binaries to do useful stuff ... oh wait.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Fedora QA] #426: All pages should include an 'info bar' linking to source repo and Test Day homepage

[Fedora QA]

#426: All pages should include an 'info bar' linking to source repo and Test Day
homepage
+---
 Reporter:  adamwill|   Owner:  jskladan
 Type:  enhancement |  Status:  new
 Priority:  major   |   Milestone:
Component:  QA tools: test day app  | Version:
 Keywords:  |  Blocked By:
 Blocking:  |
+---
 All pages generated by the test day result app -
 http://testdays.qa.fedoraproject.org/testdays - should probably have a
 small footer, or something, identifying the app, linking to the source
 repo and issue tracker (here), and the main information page for the Test
 Day process, https://fedoraproject.org/wiki/QA/Test_Days .

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: LVM thin provisioning and virt-manager

[Richard W.M. Jones]

On Tue, Oct 15, 2013 at 03:29:38PM -0600, Chris Murphy wrote:
> The better snapshots sound ideal for VM testing. Snapshot a
> successful install and then try to break the snapshot. Etc.
>
> Presently virt-manager ignores thinp pools and only creates
> conventional LV's. I haven't tried using virsh to force it to use an
> already created virtualsize LV as backing, but I'm wondering if it
> should work. If not, is there a rough time frame on such support?

Is using LVs for this over-thinking things?

Creating a snapshot of a regular file which efficiently shares the
backing disk is easy, and doesn't require root or special support:

  qemu-img create -f qcow2 -b original snapshot.qcow2

Then you can import this as a new guest in libvirt, again *without*
needing root:

  virt-install --import --name snapshot \
--ram 1024 --disk path=snapshot.qcow2,format=qcow2

And in Fedora 20 we'll have virt-builder, which makes creating the
original images quick too.  (Not to mention virt-sysprep and all the
other tools to manipulate disk images easily, without root)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 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 (or ever)?  Please stop using bogus comparisons and highly
>>> contrived tests.  They do nothing to help your argument.
>>
>> This isn't totally invalid.  I assume that some shell scripts with tight 
>> loops are the only thing that actually
>> benefits from prelinking today. People write those, unfortunately.
>
> it is - they are *not* loading a lot of dynmaic linked libraries
>
> [harry@srv-rhsoft:~]$ ldd /usr/bin/bash
> linux-vdso.so.1 =>  (0x7fffc9764000)
> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000)
> libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000)
> /lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000)

Yes because shell is a real programming language that does not have to
start tons of other binaries to do useful stuff ... oh wait.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Cole Robinson]

On 10/15/2013 05:29 PM, Chris Murphy wrote:
> The better snapshots sound ideal for VM testing. Snapshot a successful 
> install and then try to break the snapshot. Etc.
> 
> Presently virt-manager ignores thinp pools and only creates conventional 
> LV's. I haven't tried using virsh to force it to use an already created 
> virtualsize LV as backing, but I'm wondering if it should work. If not, is 
> there a rough time frame on such support?
> 

libvirt needs some explicit work to support thin pools, but no one is working
on it as far as I know. Right now libvirt's 'logical pool' (lvm volume group)
handling will actually fall apart if any thin volumes exist, though that's
fixed in upstream libvirt now by just ignoring the offending volumes.

- Cole

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 
>>> &>/dev/null;i=$[$i+1];done
>>
>> 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.
> 
> This isn't totally invalid.  I assume that some shell scripts with tight 
> loops are the only thing that actually
> benefits from prelinking today. People write those, unfortunately.

it is - they are *not* loading a lot of dynmaic linked libraries

[harry@srv-rhsoft:~]$ ldd /usr/bin/bash
linux-vdso.so.1 =>  (0x7fffc9764000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000)
libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000)
/lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000)

> I'm attaching a deliberately badly written script which should be fairly 
> representative, alas.  I can' benchmark it
> right now because the system isn't idle, but if someone else wants to have a 
> go at it, be my guest.

if you *only* can measure it if your system is *idle* than you have what we 
called
"maske dby noise" already in this thread and that is *not* significant



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 this is not useful example.
> 
> Explained in:
>   https://lists.fedoraproject.org/pipermail/devel/2013-October/190274.html
> 
>> The complexity affects end uesrs. For example, a few years ago, a bad update
>> to prelink broke everyone's systems.
> 
> We are back at the issue that every feature means more code/complexity

*we* are the whole thread about the question if prelinks preformance
gains in thereality are really worth the additional complexity

*you* are *now back* to the issue



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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?
> 
> Please keep conversations civil. Resorting to personal attacks is not
> being awesome to each other.

sorry - i tried to find a valid explaination why someone defeats
something that hard without any valid argumentation up to start
trolling multiple times



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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.
> 
> The goal of this example was to show that in a special case of shell script
> prelink does bring very significant performance improvements.
> Real world cases would have expectedly lower but still valid improvement

this is *not* a example for the real world
a typical shell script does *not* link a lot of dynmaic libraries

[harry@srv-rhsoft:~]$ ldd /usr/bin/bash
linux-vdso.so.1 =>  (0x7fffc9764000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000)
libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000)
/lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000)

prelink has only a benfit in *large* applications loading *a lot*
of libraries and those large applications like FF/TB/LibreOffice
and the Desktop are *not* opened and closed hundret times each day

so you should first understand first things that you defeat and
not come up with proveable wrong argumentations



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

LVM thin provisioning and virt-manager

[Chris Murphy]

The better snapshots sound ideal for VM testing. Snapshot a successful install 
and then try to break the snapshot. Etc.

Presently virt-manager ignores thinp pools and only creates conventional LV's. 
I haven't tried using virsh to force it to use an already created virtualsize 
LV as backing, but I'm wondering if it should work. If not, is there a rough 
time frame on such support?


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2013-10-15)

[Adam Williamson]

On Tue, 2013-10-15 at 15:19 -0400, Stephen Gallagher wrote:
> Following is the list of topics that will be discussed in the FESCo
> meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

2013-10-15 is today, Tuesday, not tomorrow, Wednesday. For the record, I
suppose the meeting will be on 2013-10-16, Wednesday.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] 2013-10-16 @ 16:00 UTC - F20 Beta Blocker Bug Review #4

[Adam Williamson]

# F20 Beta Blocker Review meeting #4
# Date: 2013-10-16
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

It's blocker review meeting time once more. Yes, yes, you can rejoice,
it's finally here!

We'll be running through the final blockers and freeze exception bugs.
The current list is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the beta release criteria [1] and should stay on
the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria

For guidance on Blocker and FreezeException bugs, please refer to
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

For the blocker review meeting protocol, see
  -https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Richard W.M. Jones]

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 blacklists
> - complicated cron job exclusion with sysconfig
> - FIPS foot-bullets
> - reduced alsr
> 
> Other people added:
> 
> - battery drain (i dont care if its cron or not, without prelink no
>   drain)
> - sluggish systems when prelink is updating
> - additional ram use when logged in for a long time

- randomly breaks OCaml programs
- prevents libguestfs AIDE checks from working

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] fractional replication monitoring proposal

[Mark Reynolds]

https://fedorahosted.org/389/ticket/47368

So we run into issues when trying to figure out if replicas are in 
synch(if those replicas use fractional replication and "strip mods").  
What happens is that an update is made on master A, but due to 
fractional replication there is no update made to any replicas. So if 
you look at the ruv in the tombstone entry on each server, it would 
appear they are out of synch.  So using the ruv in the db tombstone is 
no longer accurate when using fractional replication.


I'm proposing a new ruv to be stored in the backend replica entry: e.g. 
cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config. I'm calling 
this the "replicated ruv".  So whenever we actually send an update to a 
replica, this ruv will get updated.  Since we can not compare this 
"replicated ruv" to the replicas tombstone ruv, we can instead compare 
the "replicated ruv" to the ruv in the replica's repl agreement(unless 
it is a dedicated consumer - here we might be able to still look at the 
db tombstone ruv to determine the status).


Problems with this approach:

-  All the servers need to have the same replication configuration(the 
same fractional replication policy and attribute stripping) to give 
accurate results.


-  If one replica has an agreement that does NOT filter the updates, but 
has agreements that do filter updates, then we can not correctly 
determine its synchronization state with the fractional replicas.


-  Performance hit from updating another ruv(in cn=config)?


Fractional replication simply breaks our monitoring process.  I'm not 
sure, not without updating the repl protocol, that we can cover all 
deployment scenarios(mixed fractional repl agmts, etc). However, I 
"think" this approach would work for most deployments(compared to none 
at the moment).  For IPA, since they don't use consumers, this approach 
would work for them.  And finally, all of this would have to be handled 
by a updated version of repl-monitor.pl.


This is just my preliminary idea on how to handle this.  Feedback is 
welcome!!


Thanks in advance,
Mark

--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: prelink performance gains

[Richard W.M. Jones]

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 prelink
> >provides measurable benefits. In would be awesome if you could run
> >"unSPEC" on your systems and report back the numbers.
> 
> Please take prelink behind the barn and shoot it. Thanks.
> 
> Every year people point out how obsoleted it is, yet we can't get seem
> to rid of it.
>
> The amount of time I've wasted on prelink in combination with FIPS is
> something another decade of prelink speed gains isn't going to compensate
> me for. I think /etc/prelink.conf.d along with the cron job and its
> sysconfig override is an overengineered solution (and ugly because any
> blacklist package has to own the directory of prelink too)

Yup.  Even if prelink made things faster (which it seems it doesn't)
it wouldn't compensate for all my time it has wasted.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 this is not useful example.

Explained in:
https://lists.fedoraproject.org/pipermail/devel/2013-October/190274.html


> The complexity affects end uesrs. For example, a few years ago, a bad update
> to prelink broke everyone's systems.

We are back at the issue that every feature means more code/complexity.


> It also affects systems like tripwire,

I do not know tripwire but I guess it does not use / it should
use 'prelink -y'.


> and even rpm -V is more fragile. Most of the concerns raised are end-user
> (or sysadmin) concerns, in fact.

rpm -V is still the prelink Bug with know fix/workaround there but never
accepted/fixed in the package:
-y has false mismatches
https://bugzilla.redhat.com/show_bug.cgi?id=666143

Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Matthew Miller]

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.

> The complexity may affect software development but it should not affect end
> users.  End users then can benefit from the increased performance.

The complexity affects end uesrs. For example, a few years ago, a bad update
to prelink broke everyone's systems. It also affects systems like tripwire,
and even rpm -V is more fragile. Most of the concerns raised are end-user
(or sysadmin) concerns, in fact.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 restrain myself from not using provenpacker to
> fix this.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=841434
> https://bugzilla.redhat.com/show_bug.cgi?id=1019225

It is sad it happened but I am not prelink maintainer and I have never seen
these Bugs.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 
&>/dev/null;i=$[$i+1];done


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.


This isn't totally invalid.  I assume that some shell scripts with tight 
loops are the only thing that actually benefits from prelinking today. 
People write those, unfortunately.


I'm attaching a deliberately badly written script which should be fairly 
representative, alas.  I can' benchmark it right now because the system 
isn't idle, but if someone else wants to have a go at it, be my guest.


--
Florian Weimer / Red Hat Product Security Team


palindromes.sh
Description: application/shellscript
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Code Hosting, Development Tools and Open Source

[Tim Flink]

On Tue, 15 Oct 2013 12:23:31 -0600
Tim Flink  wrote:

> With the conversation we've been having and the persona developments,
> I propose the following:
> 
>  - create FAS groups for git-taskbot-core and git-taskbot-tasks which
>will control access to the git repos
>* use fedorahosted for now, we can migrate to github/bitbucket
> later if we want
>  - start using Phabricator as a trial to see if we think we're getting
>enough benefit from it to continue maintaining an installation
>  
> The only question left is whether we'd want to deploy phabricator in
> the fedora cloud instead of on my VPS. My concerns with fedora cloud
> are twofold:
> 
>  - I don't think we can do anything other than self-signed SSL certs
>instead of the non-self-signed cert I have on my VPS
> 
>  - I'm not sure if we can do subdomains on the cloud machines -
>phabricator expects to have a subdomain to itself, so having a
>multipurpose machine without subdomains could be a problem
> 
> I'll talk to infra today about what's possible and what they recommend
> and I'll update this thread.

I talked to infra and we should be able to get everything working
(including some backups) in a cloud instance. We'd have a self-signed
cert but that doesn't bother me so much for now.

I have a bunch of other stuff to do today, so I'm not planning on
getting this process started right now but if you have objections or
concerns, speak now :)

Tim


signature.asc
Description: PGP signature
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: prelink performance gains

[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.

The goal of this example was to show that in a special case of shell script
prelink does bring very significant performance improvements.
Real world cases would have expectedly lower but still valid improvement.

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.212s 6.218s 7.463s 6.277s 6.216s 6.203s 6.255s 6.209s 6.205s

with prelink:
6.560s 6.496s 6.501s 6.530s 6.583s 6.616s 6.511s 6.498s 6.489s 6.915s

I do not think these numbers need too deep statistical analysis.

-=without prelink
+=with prelink
 runtime linker statistics:
-  total startup time in dynamic loader: 28010379 clock cycles
+  total startup time in dynamic loader: 34141440 clock cycles
-   time needed for relocation: 19069899 clock cycles (68.0%)
+   time needed for relocation: 25601766 clock cycles (74.9%)
-number of relative relocations: 73592
+number of relative relocations: 0
-  time needed to load objects: 8138088 clock cycles (29.0%)
+  time needed to load objects: 7724814 clock cycles (22.6%)

From some looking at it I do not understand now what happens there.
It should be debugged and fixed.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Paul Wouters]

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/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 restrain myself from not using provenpacker to
fix this.

https://bugzilla.redhat.com/show_bug.cgi?id=841434
https://bugzilla.redhat.com/show_bug.cgi?id=1019225

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Stephen Gallagher]

-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?
> 
> 

Please keep conversations civil. Resorting to personal attacks is not
being awesome to each other.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJdnbMACgkQeiVVYja6o6OW+gCdGCZ6AEbjh6b8Et8kVWr+ySbM
m+8An0zLAbOKM1sjnhd0VPv22RkAXraz
=j0o+
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sunday 13th of October: SSD cache test day

[Chris Murphy]

On Oct 14, 2013, at 2:08 AM, Florian Weimer  wrote:

> On 10/10/2013 12:02 AM, Rolf Fokkens wrote:
> 
>> The Fedora SSD Cache is this sunday October 13th 2013. This Fedora Test
>> Day will focus on bcache based SSD Caching in Fedora 20.
>> 
>> https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache
>> 
>> If you're interested in trying out the new bcache SSD caching
>> functionality step by step instructions are available for:
> 
> Is there a write-up somewhere documenting what strategies are implemented by 
> bcache to keep the SSD and the hard disk contents in sync even in the event 
> of a sudden power loss?

I'd check lkml. The conversations go back a few years. But I think it's good to 
know that getting your data to stable storage means getting it to either the 
SSD (cache) or HDD (backing device). The migration from cache to backing is 
COW, so even if that were interrupted it doesn't obliterate the file system. 
Even for clean shutdowns the cache is dirty, and bcache therefore doesn't 
really distinguish between clean and unclean shutdowns - so the recovery code 
is always being exercised.

Because of COW and how much faster SSD's commit, overall I'd expect less 
potential for fs corruption in the face of unclean shutdowns, compared to a 
non-cached hard drive… assuming there are no bugs that make this supposition 
wrong.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jóhann B. Guðmundsson]

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.  If it isn't in
the default install, support for it in the other things that interact
with it will bit-rot (and maintainers will have little incentive to fix
problems).



Well for the first I'm not so sure all application that can and might 
benefit from are using it and quite frankly I seriously doubt that based 
on the many half implementation of things I've come across in the 
distribution.





If it isn't in the default install, it should probably just be removed
from the distribution.  If it improves performance noticably, then keep
it; if it doesn't, why should it be kept at all?  It has non-zero
support cost outside of the package itself.


And from my point as long as people are willing to maintain it ( which 
should indicate they are actually using it since it would be beneficial 
to at least them ) we should ship it but we should just make it option 
to install.


Again it does not improve performance it improves startup of application 
as in the application will not work any faster with it turned on...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jóhann B. Guðmundsson]

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 various applications are not compatible with 
prelink ( is everything that can be and we ship by default compatible? ) .


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.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Miloslav Trmač]

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 numbers.
>
>   - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
> 1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)
(mean 1.813, stdev 0.01245) vs. (mean 2.03, stdev 0.01103) with 4
samples is not statistically significant[1] even though the difference
leaps to the eye:  So more samples would be required to draw a
conclusion.

(Verification would be welcome: It's been years since my statistics course.)

>   - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
> 8.993, 9.075, 9.448, 9.489 without prelink)

This doesn't make sense with what I know about prelink.   Yet, similar
data have been measured earlier, and IIRC there wasn't any alternative
explanation for the result.  (One plausible explanation is that "what
I know about prelink" is wrong, of course.)
Mirek

[1] 
http://www.quantitativeskills.com/sisa/statistics/t-test.php?mean1=1.813&mean2=2.03&N1=4&N2=4&SD1=0.01245&SD2=0.01103&CI=95&CIplus=true&Submit1=Calculate
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Toshio Kuratomi]

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 of sections/segments.
> 
> This is something that ELF does not forbid so tools no longer compatible with
> non-zero file address base may have problems in future if someone wants to use
> them that way for example on some embedded system.
> 
> But another opinion can be s/he should fix them her/himself if s/he needs such
> a feature.
> 
There were similar arguments about ppc support (testing to reveal
endian-related bugs) but that didn't stop us from dropping ppc as a primary
architecture.  I don't think this is an argument that has much precedent.

-Toshio


pgpz4B_ZySewX.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 
>>> &>/dev/null;i=$[$i+1];done
>>
>> where are the numbers?
>> prove it!
> 
> 33% is the number.  It was 2.848s vs. 4.291s, that is 33.63%.

*lol* 1.44 seconds for *thousand startups*
now it's clear why you came up only with the % before asking for numbers

and you think after that somebody takes any contribution in this
thread coming from you (consider your other trolling too) serious?

you really try to tell me that if my machine get slow due prelink
is running does not do more harm than 1.44 seconds spread over
how many days you need to start a big application 1000 times?

>> and after that start your brain and compare that numbers with
>> the battery wasted by prelinking itself,
> 
> prelinking never runs on battery, or it is a bug if it does.
> At least I run notebook 24x7 on AC and only occasionally I take it out with
> battery, then prelink works perfectly for me as I have described it.

so what - and the notebook on AC which get's slow and hot
due prelink does not matter for *what* benfit - ah 1.4
seconds - wait 1.4 seconds ina total of 1000 startups

i am unsure if i now should laugh or whine

>> nobody but you is running CGI these days
>> anybody but you is using fast-cgi
> 
> 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?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

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 for it in the other things that interact
with it will bit-rot (and maintainers will have little incentive to fix
problems).

If it isn't in the default install, it should probably just be removed
from the distribution.  If it improves performance noticably, then keep
it; if it doesn't, why should it be kept at all?  It has non-zero
support cost outside of the package itself.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Wednesday's FESCo Meeting (2013-10-15)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '-MM-DD HH:MM UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1164 F20 Changes - Progress on Changes Freeze
.fesco 1164
https://fedorahosted.org/fesco/ticket/1164

#topic #1166 F20 System Wide Change: Migrate to Bluez 5 -
https://fedoraproject.org/wiki/Changes/Bluez5
.fesco 1166
https://fedorahosted.org/fesco/ticket/1166

#topic #1170 Working Group call for Volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170

= New business =

#topic #1181 Fedora still vulnerable to BEAST
.fesco 1181
https://fedorahosted.org/fesco/ticket/1181

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJdlTUACgkQeiVVYja6o6P2rACghfZjrdfFZvJvTR0RoCw/cvhl
HRAAn1kX8CvSbGbUnxT0GOEgB/PTFuGn
=NowH
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 
> > &>/dev/null;i=$[$i+1];done
> 
> where are the numbers?
> prove it!

33% is the number.  It was 2.848s vs. 4.291s, that is 33.63%.


> and after that start your brain and compare that numbers with
> the battery wasted by prelinking itself,

prelinking never runs on battery, or it is a bug if it does.
At least I run notebook 24x7 on AC and only occasionally I take it out with
battery, then prelink works perfectly for me as I have described it.


> nobody but you is running CGI these days
> anybody but you is using fast-cgi

OT: I use mod_perl for majority of my web code.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sunday 13th of October: SSD cache test day

[Rolf Fokkens]

On 10/14/2013 10:08 AM, Florian Weimer wrote:
Is there a write-up somewhere documenting what strategies are 
implemented by bcache to keep the SSD and the hard disk contents in 
sync even in the event of a sudden power loss?

This is good place to start: http://bcache.evilpiepirate.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 that's the case,
>> than _any_ effort is not worth the added complexity, overhead, etc. of
>> prelink.
> 
> 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 numbers?
prove it!

and after that start your brain and compare that numbers with
the battery wasted by prelinking itself, consider how realistic
it is that you start 1000 times a large application which benefits
from prelink until it get the next update

and *no* don#t come again with "but CGI"
nobody but you is running CGI these days
anybody but you is using fast-cgi which does not fire up a new
process for each request and so prelink is out of the game



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 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 the added complexity, overhead, etc. of
> prelink

forget it - he is just trolling and not interested ina technical
discussion or numbers proving the gain of prelink

otherwise he would prove it or if he can't do so stop defeat
prelink because in case of no significant gain it's pretty
clear that prelink should no longer be in the default install

besides negative impact because: *any* running code with out
a real beenfit is *bad* for maintainence and security reasons

period



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 feature.  That -O2 vs. -O0 build is a good comparison.

this is just trolling

>> - FIPS foot-bullets
> I really do not care and do not run FIPS.  Disable/uninstall prelink for FIPS.

i do not care about prelink
enable/install prelink

>> - reduced alsr
> 
> I do not know the details but the network facing daemons are already PIE while
> most of the binaries - those not facing untrusted data - have no use for PIE.

ASLR is about *untsrusted input data*

you *really* think your browser, office, pdf-reader does not act
with untrusted input or if that is the case this is representative
for the userbase?

without ASLR and prelink which is the reason not build PIE and start
Firefox directly after updates you have *no randomization at all*

if you think that does not matter why do you think ASLR exists

>> So far you seem to say "those are not prelink bugs".
> 
> True.

*where are the numbers* proving the benfits?
"it's faster" and "it's for performance" are no numbers
if you defeat something *prove* why or be quiet
anything else is *trolling*

>> Just the FIPS issue for me
> 
> That's for you but majority of Fedora users do not run in FIPS mode.

the majority of Fedora users does not care about prelink
as well becaus ethey have it only installe dbecause it's
default and the performance improvement is *not* that
large these days *until you prove* it isa

>> Furthermore, in the past I've indicated that we should have support for
>> systems booted in FIPS mode with fips=1, where though libraries and
>> programs that could not be prelinked should be unprelinked, as the
>> sysadmin specifically told us (via fips=1) that they value security over
>> speed gains)
> 
> OK, great, so unprelink the programs.

OK, great, don't prelink them without a user decided to do so

>> prelink has served us in the past. It's time to let it go.
> 
> People continually give up on software performance with better hardware.
> 64-bit systems nowadays run commonly slower than did the 8-bits in 1980s

*prove the performance benfit with numbers*
only repeat the same again and agin does not make it the truth

BTW:
64Bit systems these days are in most cases *faster* because
software can use CPU capabilities which did not exist not
long ago and some of them are only available in 64bit mode



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 else
>> the better way is solve the root cause
> 
> The root cause is really the update system.  Why should I look for what daemon
> to restart by hand?  It should happen automatically, it is even a security
> hole if nightly yum updates a daemon but its old version remains running.
> IIRC it is some systemd feature in development but I cannot find it now.

*you need to restart no-PIE binaries after prelink because otherwise no ASLR*

> 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.

no

>>> This is a known prelink Bug:
>>> -y has false mismatches
>>> https://bugzilla.redhat.com/show_bug.cgi?id=666143
>>>
>>> Just the evil Fedora Bugs autoclose has already closed it but it is still
>>> valid.  I have provided even a single line fix there.
>>
>> you can always point with your finger somewhere else
>> the better way is solve the root cause
> 
> 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.

*stop trolling*

 there are people wich shut down or suspend machines when they are not in 
 use
 how do you imagine the cronjob run while they are not in use for this
 *majority* of users?
>>>
>>> These users really should uninstall prelink as they cannot use it
>>
>> if the majority should uninstall something because they can't
>> use it it must not be active in a default setup
> 
> If the majority of Fedora users then yes.  IMO Fedora is more used on servers
> but I really do not know the user base.

*lol* Fedora != RHEL/CentOS and that said from one running
Fedora in production *but* i am aware that i am *not*
the majority in that case

>>> BTW all my servers run 24x7
>>
>> and *there* you do *not* need prelink because the theoretical gain
>> in faster startup does *not matter*
> 
> It does matter, I run even large builds there, regression testing, besides
> that even web server CGIs benefit from it.  "server" is a wide term.

come on where the numbers?

>> so, and now come on and list some *real* benefits,
> 
> Improved performance.

come on where the numbers?

>> take the wasted time into account
> 
> If you find software development of performance features a wasted time then
> I see it really does not make sense to discuss it more.

come on where the numbers of the better performance?

>> stop to defeat prelink in the default
>> install and agree that it has to be removed from it
> 
> I do not say anything about prelink in the default install as I have no idea
> what is the default Fedora user.  

*this topic is about have prelink by default installed*

> But it is a useful feature at least on
> servers and 24x7 running workstations

yeah, where you update, reboot, login and start your Firefox
with no ASLR which runs after that 2,3,4,5 days - oh my god
what a nonsense to think the 200 ms at startup of the browser
is worth the time to defeat it

*you have no ASLR at all* in such situations because the
on-time-randomize happens after you started your browser
which keeps running

don't get me wrong but honestly i doubt you are the right person to
discuss such technical stuff



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

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 (or ever)?  Please stop using bogus comparisons and highly
contrived tests.  They do nothing to help your argument.

The biggest (real world) gain for prelink was always in the large
applications that link many libraries, such as LibreOffice.  The start
of this thread said that tests showed no significant gain anymore, at
least in the poster's setup.  If that is indeed the case, then there's
no reason to keep prelink.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 that's the case,
> than _any_ effort is not worth the added complexity, overhead, etc. of
> prelink.

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

The complexity may affect software development but it should not affect end
users.  End users then can benefit from the increased performance.

Here both developers want to avoid any increased software complexity and also
in some cases users suffer due to some lasting bugs (such as the cron issue).


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 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 the added complexity, overhead, etc. of
prelink.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 feature.  That -O2 vs. -O0 build is a good comparison.


> - FIPS foot-bullets

I really do not care and do not run FIPS.  Disable/uninstall prelink for FIPS.


> - reduced alsr

I do not know the details but the network facing daemons are already PIE while
most of the binaries - those not facing untrusted data - have no use for PIE.


> Other people added:
> 
> - battery drain (i dont care if its cron or not, without prelink no
>   drain)
> - sluggish systems when prelink is updating

This is a bug in cron and/or people not running 24x7 machine should not use
prelink at all.


> - additional ram use when logged in for a long time

Answered in:
https://lists.fedoraproject.org/pipermail/devel/2013-October/190237.html


> So far you seem to say "those are not prelink bugs".

True.


> Just the FIPS issue for me

That's for you but majority of Fedora users do not run in FIPS mode.


> Furthermore, in the past I've indicated that we should have support for
> systems booted in FIPS mode with fips=1, where though libraries and
> programs that could not be prelinked should be unprelinked, as the
> sysadmin specifically told us (via fips=1) that they value security over
> speed gains)

OK, great, so unprelink the programs.


> prelink has served us in the past. It's time to let it go.

People continually give up on software performance with better hardware.
64-bit systems nowadays run commonly slower than did the 8-bits in 1980s.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 else
> the better way is solve the root cause

The root cause is really the update system.  Why should I look for what daemon
to restart by hand?  It should happen automatically, it is even a security
hole if nightly yum updates a daemon but its old version remains running.
IIRC it is some systemd feature in development but I cannot find it now.

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.


> > This is a known prelink Bug:
> > -y has false mismatches
> > https://bugzilla.redhat.com/show_bug.cgi?id=666143
> > 
> > Just the evil Fedora Bugs autoclose has already closed it but it is still
> > valid.  I have provided even a single line fix there.
> 
> you can always point with your finger somewhere else
> the better way is solve the root cause

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.


> >> there are people wich shut down or suspend machines when they are not in 
> >> use
> >> how do you imagine the cronjob run while they are not in use for this
> >> *majority* of users?
> > 
> > These users really should uninstall prelink as they cannot use it
> 
> if the majority should uninstall something because they can't
> use it it must not be active in a default setup

If the majority of Fedora users then yes.  IMO Fedora is more used on servers
but I really do not know the user base.


> > BTW all my servers run 24x7
> 
> and *there* you do *not* need prelink because the theoretical gain
> in faster startup does *not matter*

It does matter, I run even large builds there, regression testing, besides
that even web server CGIs benefit from it.  "server" is a wide term.


> so, and now come on and list some *real* benefits,

Improved performance.


> take the wasted time into account

If you find software development of performance features a wasted time then
I see it really does not make sense to discuss it more.


> stop to defeat prelink in the default
> install and agree that it has to be removed from it

I do not say anything about prelink in the default install as I have no idea
what is the default Fedora user.  But it is a useful feature at least on
servers and 24x7 running workstations.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

On 10/15/2013 02:27 PM, Jakub Jelinek wrote:
> On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
>> There is no effective security difference between accessing the randomized
>> stack guard value from a global variable or a value stored in the dynamic
>> thread vector.
>>
>> It is only a performance optimization. The choice of a global variable vs. 
>> DTV offset has only to do with the speed of access of the stack guard.
> 
> DTV access is of course going to be expensive, after all, that is a function
> call, the question was about reserving a word at fixed constant offset from
> the TLS base and how expensive that is vs. global variable access.
> For soft FP I guess global variable access must win, for -mtp=cp15
> ]it depends on how fast the mrc instruction is.

I talk about DTV, but I should really just say constant offset from TP
since that's what I mean. I don't actually mean using a TLS variable.

Will Newton tested the global variable access code on soft and hard TP
configurations and to quote some initial discussions:
https://sourceware.org/ml/libc-ports/2013-09/msg00134.html
~~~
From a back of the envelope calculation the cost of accessing TLS is
one cycle faster than accessing a global in best case (e.g.
Cortex-A15), considerably slower in common case (50-60 cycles,
Cortex-A9) and slower still in worst case (function call to libgcc and
the kernel, ARMv4/ARMv5).
~~~
Therefore for 32-bit ARM it was decided that a global variable was the
best choice.

For AArch64 it will definitely be a reserved word at a constant offset
from the TP since that's going to be fastest.

Does that clarify things?

Cheers,
Carlos.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Matthew Garrett]

On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote:
> 
> On Oct 15, 2013, at 10:36 AM, Matthew Garrett  wrote:
> 
> > On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
> > 
> >> Or maybe Intel would be forthcoming. It's their hardware.
> > 
> > Not in this case. Target display mode is a vendor extension, and 
> > switching it will be vendor specific.
> 
> 
> Too bad. I wonder if this switching extension is being obfuscated from 
> reverse engineering with these "smart" cables Apple's producing.

I can't see how. It works fine without any kind of special cable.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 with your finger somewhere else
the better way is solve the root cause

>> your notebooks are running 24 hours a day?
>> really?
> 
> OT: Yes, really.  I use it with remote display+keyboard as a workstation.

as i often enough heard here: the world is not turning around you

>> and try what happens if there where some updates and prelink did
>> not run before the next rkhunter startip -> you get alarm mails
> 
> This is a known prelink Bug:
>   -y has false mismatches
>   https://bugzilla.redhat.com/show_bug.cgi?id=666143
> 
> Just the evil Fedora Bugs autoclose has already closed it but it is still
> valid.  I have provided even a single line fix there.

you can always point with your finger somewhere else
the better way is solve the root cause

>> there are people wich shut down or suspend machines when they are not in use
>> how do you imagine the cronjob run while they are not in use for this
>> *majority* of users?
> 
> These users really should uninstall prelink as they cannot use it

if the majority should uninstall something because they can't
use it it must not be active in a default setup

> BTW all my servers run 24x7

and *there* you do *not* need prelink because the theoretical gain
in faster startup does *not matter*

so, and now come on and list some *real* benefits, stop to point
with your fingers how many people should fix these and and that
to work better with prelink, take the wasted time into account
if you consider the prelink-benefits and if you can't find
*really* good arguments stop to defeat prelink in the default
install and agree that it has to be removed from it

only the time wasted multiple times a year with discussions and
fixing this and that to work with prelink makes it's benefits
for gain 200 ms here and there non existent



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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" output caused by prelink
>>
>> Sorry I do not see what disadvantage is it?
> 
> If you install updates, reboot, and log in, you are running
> non-prelinked binaries/libraries.  If you don't log out (just lock
> screen or suspend for example), when you next use the system after
> prelink has run, new programs will use the prelinked bins/libs.  Now you
> are wasting a chunk of RAM, as it can't be shared between non-prelinked
> and prelinked bins/libs

*and* because prelink is the reason *not* build a lot of packages
with position independent code because it can't be prelinked and
the excuse is that prelink itself does a little randomization
in the case you reboot after updates and login you have pretty
well *disabled ASLR at all* until re-login after prelink did
it's job

from security point of view prelink is nothing else than a
nightmare and it stands in the way get the whole distribution
hardened

for what gain?
for one where you can't make a distinct between prelink optimization
our typical noise on a multi-threaded operating system?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?

don't get me wrong but *please* take some security education because with
"-O0" https://fedoraproject.org/wiki/Security_Features?rd=Security/Features
would not work

*and* prelink works against ASLR

>> In general prelink makes things more complex for negligible gains, its
>> worth is highly questionable.
> 
> I am aware of it, I have spent a lot of time making tools prelink compatible.
> But even compilers have very complex parts for negligible gains.

and pointing with the finger somewhere and saying "there is someting bad"
makes bad things better? not in the reality!

>> I just hope you are not saying that there is a doubt there are
>> disadvantages.
> 
> I really have not yet seen any valid one.

no - you refused to understand them

>> The real question here is whether advantages supersede disadvantges, and
>> given the only advantage seem to be performance and it is lost in noise,
> 
> I would not say it is lost in noise but let's say it is not big

if benchmarks sometimes are faster without and sometimes with prelink
the only conlcusion is that it got lost in the noise



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 disadvantage is it?

have fun in distinct between prelink caused "needs-restarting" or real

>> * look at the wasted cycles of running prelink itself and compare to the gain
> 
> the cycles of prelink happen during night when nobody waits for anything.
> The gain happens when user waits until the program starts.

your notebooks are running 24 hours a day?
really?

>> in the past on notebooks i hated prelink and god bless the maintainer which
>> removed the prelink-require out of rkhunter which was pervert
>>
>> most of the time i noticed the weak performance while prelink ran
>> between that i got alarmed all the time by rkhunter-notifies
>> *because* i should prelink this and that file
> 
> Sorry I do not see how is rkhunter related and what is the disadvantage.

well, read what rkhunter does
it verifies file integrity
wonderful idea have a software default touching the binaries

and try what happens if there where some updates and prelink did
not run before the next rkhunter startip -> you get alarm mails

> If you mean that prelink ever runs while you sit at the computer then it is
> a bug in cron, not in prelink. /etc/cron.daily/mlocate has a similar problem

there are people wich shut down or suspend machines when they are not in use
how do you imagine the cronjob run while they are not in use for this
*majority* of users?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 prelink (see
> https://lists.fedoraproject.org/pipermail/devel/2013-April/181376.html
> and following).

try to understand what you read there

* update installed
* prelink doe *one time* randomization

until the next update/full prelink there is no randomization

because prelink a lot of binaries are not PIE code

* update
* reboot
* applications are running
* prelink does the one time randomization
* the apps are still running and not randomized at all





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-1.fc20

[Paul Howarth]

The lightweight tag 'perl-DateTime-Set-0.33-1.fc20' was created pointing to:

 088a2fe... Update to 0.33
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jakub Jelinek]

On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
> There is no effective security difference between accessing the randomized
> stack guard value from a global variable or a value stored in the dynamic
> thread vector.
> 
> It is only a performance optimization. The choice of a global variable vs. 
> DTV offset has only to do with the speed of access of the stack guard.

DTV access is of course going to be expensive, after all, that is a function
call, the question was about reserving a word at fixed constant offset from
the TLS base and how expensive that is vs. global variable access.
For soft FP I guess global variable access must win, for -mtp=cp15
]it depends on how fast the mrc instruction is.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-1.fc21

[Paul Howarth]

The lightweight tag 'perl-DateTime-Set-0.33-1.fc21' was created pointing to:

 088a2fe... Update to 0.33
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: prelink performance gains

[Paul Wouters]

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-bullets
- reduced alsr

Other people added:

- battery drain (i dont care if its cron or not, without prelink no
  drain)
- sluggish systems when prelink is updating
- additional ram use when logged in for a long time

So far you seem to say "those are not prelink bugs".

Just the FIPS issue for me (speaking as a member of the Red Hat Security
Group) is enough to say that if the gains are too small to measure, that
it's time for Ocam's Razor and not make our systems needlesly complex.

Furthermore, in the past I've indicated that we should have support for
systems booted in FIPS mode with fips=1, where though libraries and
programs that could not be prelinked should be unprelinked, as the
sysadmin specifically told us (via fips=1) that they value security over
speed gains)

prelink has served us in the past. It's time to let it go.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:

> Pointer mangling is useful, but we can roll that change into an update
> and it should not in my opinion block F20.
> 
> I've filed:
> Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
> https://bugzilla.redhat.com/show_bug.cgi?id=1019452

Great. Thanks, Carlos!

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

On 10/15/2013 12:53 PM, Matthew Garrett wrote:
> On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
>> On 10/14/2013 10:55 AM, Matthew Garrett wrote:
>>> Did the arm32 portions of this end up being completed for F20?
>>
>> For 32-bit ARM on f20:
>>
>> - Stack guard:
>>   - Existing glibc support provides stack guard value in global
>> variable and is used by existing runtime. Regression tests are
>> passing in glibc testsuite. Verified working. Upstream verified
>> that global variable is the best compromise for performance across
>> all 32-bit ARM targets (TLS will be too slow in the average case).
> 
> What's the effective difference in security between this and the 
> existing ports?

There is no effective security difference between accessing the randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.

It is only a performance optimization. The choice of a global variable vs. 
DTV offset has only to do with the speed of access of the stack guard.

>> - Pointer mangling:
>>   - Not supported.
> 
> Do we ship it in the x86 ports?

We do.

>> Upstream glibc 2.19 summary:
>>
>> - Stack guard support already present using global variable.
>>
>> - Will have pointer encryption support using global variable, 
>>   and could be a candidate for backport to f20.
> 
> Cool. This is a runtime change, right? There's no requirement for a 
> rebuild to take advantage of it?

That is correct. It is only an internal glibc change that does not
require any rebuilds for applications to take advantage of this.
The pointer mangling is hidden from the application.

>> Do we need pointer mangling? If so then we need someone to file an
>> f20 specific bug so the glibc team can look at backporting the fix.
>> I won't commit to it until I review exactly what might need changing.
> 
> The aim was for parity of important features, but it doesn't seem like 
> we've ever advertised pointer guard as a Fedora feature so I'm not 
> personally that worried.

Pointer mangling is useful, but we can roll that change into an update
and it should not in my opinion block F20.

I've filed:
Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=1019452

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Simo Sorce]

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 away most of
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?

This comparison makes no sense, and you know it.

If you want to negate others arguments so not to have to address them
suit yourself.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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.


> your notebooks are running 24 hours a day?
> really?

OT: Yes, really.  I use it with remote display+keyboard as a workstation.


> and try what happens if there where some updates and prelink did
> not run before the next rkhunter startip -> you get alarm mails

This is a known prelink Bug:
-y has false mismatches
https://bugzilla.redhat.com/show_bug.cgi?id=666143

Just the evil Fedora Bugs autoclose has already closed it but it is still
valid.  I have provided even a single line fix there.


> there are people wich shut down or suspend machines when they are not in use
> how do you imagine the cronjob run while they are not in use for this
> *majority* of users?

These users really should uninstall prelink as they cannot use it.
BTW all my servers run 24x7.


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 prelink (see
https://lists.fedoraproject.org/pipermail/devel/2013-April/181376.html
and following).
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Josh Boyer]

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 throw away most of
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?
>
>
>> In general prelink makes things more complex for negligible gains, its
>> worth is highly questionable.
>
> I am aware of it, I have spent a lot of time making tools prelink compatible.
> But even compilers have very complex parts for negligible gains.
>
>
>> I just hope you are not saying that there is a doubt there are
>> disadvantages.
>
> I really have not yet seen any valid one.
>
>
>> The real question here is whether advantages supersede disadvantges, and
>> given the only advantage seem to be performance and it is lost in noise,
>
> I would not say it is lost in noise but let's say it is not big.

The definition of negligible (the word you keep using to describe the
performance benefits is:

"so small or unimportant as to be not worth considering; insignificant."

That is exactly the same as "lost in noise".

Perhaps you want to use some word other than negligible to describe
the performance benefits, because right now your argumentation is very
confusing.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 prelink.

I understand you may find a machine low on RAM where the overall performance
with prelink will be lower.  That is a special case, not an average user.
You can uninstall prelink on such underpowered machine.

I have no numbers to back my performance guess above.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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
compilers and half of debuggers, which are all needlessly complex and prone to
faults due to -O2.  Do we want to build simple system or good system?


> In general prelink makes things more complex for negligible gains, its
> worth is highly questionable.

I am aware of it, I have spent a lot of time making tools prelink compatible.
But even compilers have very complex parts for negligible gains.


> I just hope you are not saying that there is a doubt there are
> disadvantages.

I really have not yet seen any valid one.


> The real question here is whether advantages supersede disadvantges, and
> given the only advantage seem to be performance and it is lost in noise,

I would not say it is lost in noise but let's say it is not big.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: sysctl behavior for docker-io

[Miloslav Trmač]

On Mon, Oct 7, 2013 at 3:47 PM, Richard W.M. Jones  wrote:
> Another way to look at it might be: Since a lot of people have libvirt
> installed (it's the default isn't it?) and hence forwarding has been
> on for many people for a long time, what harm is it causing?

RFC 1812
> 2.2.8.1 Embedded Routers
>
> The embedded router feature seems to make building a network easy, but 
>it has a number of hidden pitfalls:
>
> (1) If a host has only a single constituent-network interface, it should not 
> act as a router.
>
> For example, hosts with embedded router code that gratuitously forward 
> broadcast packets or datagrams on the same net often cause packet avalanches.

I'm almost certain that some other RFC requires forwarding for
~workstations to be opt-in, but I couldn't find it.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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" output caused by prelink
> 
> Sorry I do not see what disadvantage is it?

If you install updates, reboot, and log in, you are running
non-prelinked binaries/libraries.  If you don't log out (just lock
screen or suspend for example), when you next use the system after
prelink has run, new programs will use the prelinked bins/libs.  Now you
are wasting a chunk of RAM, as it can't be shared between non-prelinked
and prelinked bins/libs.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Chris Murphy]

On Oct 15, 2013, at 10:36 AM, Matthew Garrett  wrote:

> On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
> 
>> Or maybe Intel would be forthcoming. It's their hardware.
> 
> Not in this case. Target display mode is a vendor extension, and 
> switching it will be vendor specific.


Too bad. I wonder if this switching extension is being obfuscated from reverse 
engineering with these "smart" cables Apple's producing.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: sysctl behavior for docker-io

[Miloslav Trmač]

On Sun, Oct 6, 2013 at 11:32 PM, Lennart Poettering
 wrote:
> This is the general problem that IP forwarding is no local setting, and
> that the global setting has no inherent concept of ownership or
> refcounting.

The proper place for this seems to be firewalld, which should not only
control the individual sysctl, but also the more detailed forwarding
semantics (i.e. the application should request a specific, fairly
high-level forwarding scenario ("do a NAT of all traffic from
$this_ethernet and $this_wifi to $that ethernet"), and the firewall
should manage both iptables and sysctl.

I guess this is suggestion wouldn't be currently met with universal
approval, would it?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Simo Sorce]

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 a negligible performance
> and negligible battery optimization nowadays.
> 
> I just do not understand why to give up on that negligible optimization when
> it brings no disadvantages.

Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
modification of binaries in itself is pretty perverse to gain just
imperceptible performance gains. Many tools need to juggle the fact
these binaries have been changed, and make checkers more complex and
prone to faults.

In general prelink makes things more complex for negligible gains, its
worth is highly questionable.

> The disagreement here is whether it brings some disadvantages or not.

I just hope you are not saying that there is a doubt there are
disadvantages.

The real question here is whether advantages supersede disadvantges, and
given the only advantage seem to be performance and it is lost in noise,
I hardly see how the advantages are enough to justify using it these
days.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 disadvantage is it?


> * look at the wasted cycles of running prelink itself and compare to the gain

the cycles of prelink happen during night when nobody waits for anything.
The gain happens when user waits until the program starts.


> in the past on notebooks i hated prelink and god bless the maintainer which
> removed the prelink-require out of rkhunter which was pervert
> 
> most of the time i noticed the weak performance while prelink ran
> between that i got alarmed all the time by rkhunter-notifies
> *because* i should prelink this and that file

Sorry I do not see how is rkhunter related and what is the disadvantage.

If you mean that prelink ever runs while you sit at the computer then it is
a bug in cron, not in prelink.  /etc/cron.daily/mlocate has a similar problem.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 performance
> and negligible battery optimization nowadays.
> 
> I just do not understand why to give up on that negligible optimization when
> it brings no disadvantages.
> 
> The disagreement here is whether it brings some disadvantages or not.
> 
> So the discussion should rather be if the average (default) user faces the
> claimed disadvantages or not (*), and therefore whether prelink should be
> installed by default or not.

* 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
* look at the wasted cycles of running prelink itself and compare to the gain

in the past on notebooks i hated prelink and god bless the maintainer which
removed the prelink-require out of rkhunter which was pervert

most of the time i noticed the weak performance while prelink ran
between that i got alarmed all the time by rkhunter-notifies
*because* i should prelink this and that file

hence - at the end of the day prelink itself consumed more CPU
and did more harm as it ever could have gained performance





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Anyone else using and interested in co-maintaining sogo?

[Frankie Onuonga]

Hi,

sounds amazing.
I could take it up but I can not promise to do so soon.
I have some things on my hands that will need about a month to finish up.

thanks,




On Tue, Oct 15, 2013 at 4:35 PM, Sandro Mani  wrote:

> Hi,
>
> Needing a calendar server for the company, I've ended up packaging the
> groupware server SOGo [1], which is a neat MS Exchange alternative. SRPM of
> sogo plus deps are here:
>
> http://smani.fedorapeople.org/**review/sogo-2.0.7-1.fc21.src.**rpm
> http://smani.fedorapeople.org/**review/sope-2.0.7-1.fc21.src.**rpm
> http://smani.fedorapeople.org/**review/lasso-2.3.6-1.fc21.src.**rpm
>
> I think the packages are pretty decent and fit for inclusion into Fedora,
> and they might well be of interest to other people. However, I am hestitant
> to post them for review since Objective-C and GNUStep are not really known
> territory for me, and I'm also rather unexperienced with stuff like LDAP.
>
> So, anyone who would like to see these in Fedora and is willing to help
> out if things go wrong?
>
> Thanks,
> Sandro
>
>
> [1] http://www.sogo.nu/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
> Fedora Code of Conduct: 
> http://fedoraproject.org/code-**of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 performance
and negligible battery optimization nowadays.

I just do not understand why to give up on that negligible optimization when
it brings no disadvantages.

The disagreement here is whether it brings some disadvantages or not.

So the discussion should rather be if the average (default) user faces the
claimed disadvantages or not (*), and therefore whether prelink should be
installed by default or not.


(*)
I find there for example a problem that nightly prelink will run even if you
are currently running on battery.  But that affects more cron scripts and it
is a cron bug, not prelink bug.


> "unSPEC" is super easy to run and you are encouraged to get all the
> numbers and stats you need.

I intentionally do not post the numbers but it seems to me prelink does bring
negligible performance (and battery) gain for LibreOffice on my system.
It is just difficult to measure if you do not trust LD_DEBUG=statistics.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
> On 10/14/2013 10:55 AM, Matthew Garrett wrote:
> > Did the arm32 portions of this end up being completed for F20?
> 
> For 32-bit ARM on f20:
> 
> - Stack guard:
>   - Existing glibc support provides stack guard value in global
> variable and is used by existing runtime. Regression tests are
> passing in glibc testsuite. Verified working. Upstream verified
> that global variable is the best compromise for performance across
> all 32-bit ARM targets (TLS will be too slow in the average case).

What's the effective difference in security between this and the 
existing ports?

> - Pointer mangling:
>   - Not supported.

Do we ship it in the x86 ports?

> Upstream glibc 2.19 summary:
> 
> - Stack guard support already present using global variable.
> 
> - Will have pointer encryption support using global variable, 
>   and could be a candidate for backport to f20.

Cool. This is a runtime change, right? There's no requirement for a 
rebuild to take advantage of it?

> Do we need pointer mangling? If so then we need someone to file an
> f20 specific bug so the glibc team can look at backporting the fix.
> I won't commit to it until I review exactly what might need changing.

The aim was for parity of important features, but it doesn't seem like 
we've ever advertised pointer guard as a Fedora feature so I'm not 
personally that worried.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

On 10/14/2013 10:55 AM, Matthew Garrett wrote:
> On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote:
> 
>> Next steps:
>> - Verify libssp works correctly on 32-bit ARM.
>> - Look at enhancing the existing support in glibc.
>>   - Add TLS stack guard.
>>   - Add TLS pointer guard.
>>   - Add pointer mangle/demangle support.
>> - Enhance aarch64 to support the same set of features.
> 
> Did the arm32 portions of this end up being completed for F20?

For 32-bit ARM on f20:

- Stack guard:
  - Existing glibc support provides stack guard value in global
variable and is used by existing runtime. Regression tests are
passing in glibc testsuite. Verified working. Upstream verified
that global variable is the best compromise for performance across
all 32-bit ARM targets (TLS will be too slow in the average case).

- Pointer mangling:
  - Not supported.

Upstream glibc 2.19 summary:

- Stack guard support already present using global variable.

- Will have pointer encryption support using global variable, 
  and could be a candidate for backport to f20.
 
  ~~~
  commit b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8
  Author: Will Newton 
  Date:   Wed Aug 7 13:55:30 2013 +0100

ARM: Add pointer encryption support.

Add support for pointer encryption in glibc internal structures in C
and assembler code. Pointer encryption is a glibc security feature
described here:

https://sourceware.org/glibc/wiki/PointerEncryption

The ARM implementation uses global variables instead of thread pointer
relative accesses to get the value of the pointer encryption guard
because accessing the thread pointer can be very expensive on older
ARM cores.
  ...
  ~~~

Do we need pointer mangling? If so then we need someone to file an
f20 specific bug so the glibc team can look at backporting the fix.
I won't commit to it until I review exactly what might need changing.

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Matthew Garrett]

On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:

> Or maybe Intel would be forthcoming. It's their hardware.

Not in this case. Target display mode is a vendor extension, and 
switching it will be vendor specific.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Dhiru Kholia]

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 problem we even disagree how to read the numbers.  There aren't
> enough numbers (+their stats).

Jan,

Yes, the numbers I posted have zero "scientific" value and are simply
crude measurements.

In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.

Even if these numbers don't demonstrate that, they should *at least*
make us doubt prelink's relevance. I am going to quote Matthew on this,
"Even though prelink is currently in, the burden of proof should be on
demonstrating its continued usefulness, and the threshold for that
should be be higher than marginal noise. When in doubt, let's go for
smaller and more simple".

"unSPEC" is super easy to run and you are encouraged to get all the
numbers and stats you need.

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora and ECDHE: now supported in OpenSSL

[Paul Wouters]

On Tue, 15 Oct 2013, Reindl Harald wrote:


since OpenSSL in Fedora from now on supports ECDHE
depending software needs to be rebuilt to make use
of it as well as libraries like NSS/GNUTLS should
do the same and depending packages like Firefox
needs a rebuild against refreshed NSS to support
it also on the client side


Is there an updated page about ECC in Fedora? What ECC
curves are allowed? What implementations?

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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:
> 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 "unSPEC" to do
>   independent validation of these numbers.
> 
>   - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
> 1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)
> 
>   - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 
> 2.299
> with prelink), (2.311, 2.052, 2.047, 2.037 without prelink)
> 
>   - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
> 8.993, 9.075, 9.448, 9.489 without prelink)
> 
>   - danpb (T530): I see basically no measurable difference in times with or
> without prelink - quite a lot of variation, but all in same ballpark,
> (8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with
> prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without
> prelink).
> 
> - For building kernels (using the "kernel-bench" [3] component of unSPEC
>   suite), prelink saved <= 250 ms over the non-prelink environment
>   (which took 1m19.138s). hkario even reports worse performance numbers
>   for the prelink environment. Additionally, we have specialized
>   softwares like ccache and distcc to solve long-compilation-time
>   problems.
> 
> 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 could run
> "unSPEC" on your systems and report back the numbers.
> 
> "unSPEC" is easy to use and doesn't take much time (or steps) to run.
> For more information, please see the following links.
> 
> References:
> 
> [1] https://github.com/kholia/unSPEC
> [2] https://github.com/kholia/unSPEC/tree/master/LibreOffice
> [3] https://github.com/kholia/unSPEC/tree/master/kernel-bench



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora and ECDHE: now supported in OpenSSL

[Reindl Harald]

since OpenSSL in Fedora from now on supports ECDHE
depending software needs to be rebuilt to make use
of it as well as libraries like NSS/GNUTLS should
do the same and depending packages like Firefox
needs a rebuild against refreshed NSS to support
it also on the client side

i made some triage today
_

openssl:
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108

nss-softokn
https://bugzilla.redhat.com/show_bug.cgi?id=1019244

nss
https://bugzilla.redhat.com/show_bug.cgi?id=1019245

firefox
https://bugzilla.redhat.com/show_bug.cgi?id=1019247

thunderbird:
https://bugzilla.redhat.com/show_bug.cgi?id=1019249

httpd:
https://bugzilla.redhat.com/show_bug.cgi?id=1019251

dovecot:
https://bugzilla.redhat.com/show_bug.cgi?id=1019253

postfix:
https://bugzilla.redhat.com/show_bug.cgi?id=1019254

openssh:
https://bugzilla.redhat.com/show_bug.cgi?id=1019256

dbmail:
https://bugzilla.redhat.com/show_bug.cgi?id=1019259




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Daniel P. Berrange]

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 Fedora. That is what this email thread is seeking to confirm.
> 
> There is missing some statistics behind it such as deviation computation.
> And 4 tests/numbers seem to be too few to compute any real statistics.
> 
> Some numbers in the initial mail even show as if prelink is slowing down the
> startup.  Technically I do not understand how it can happen and IMHO rather
> the numbers are bogus.  If there is a proven performance degradation it would
> be good to know the reason.

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.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] please review: Ticket 47519 - memory leaks in access control

[Mark Reynolds]

https://fedorahosted.org/389/ticket/47519

https://fedorahosted.org/389/attachment/ticket/47519/0001-Ticket-47519-memory-leaks-in-access-control.patch

--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Target Display Mode in Fedora

[Chris Murphy]

On Oct 15, 2013, at 2:15 AM, David Airlie  wrote:

> 
>> The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which
>> lets them be used as a Display for another computer. Apple calls it Target
>> Display Mode, though HP doesn't seem to have a special name for it. This is
>> really quite useful, I've used an iMac hooked up to a Linux machine at a
>> previous job, and it's awesome to switch between the two machines when
>> you've only got space for one display on the desk. The feature is invoked by
>> a fairly non-standard keyboard combination. Here is a video illustrating
>> what I mean (
>> http://www.youtube.com/watch?feature=player_detailpage&v=Y7_OZgBX8kQ#t=60 ),
>> note how he switches the iMac from being the display for the MacBook to
>> being an iMac again via keyboard shortcut (sort of off-screen).
>> 
>> However, this feature is only implemented in OS X and Windows (via HP's My
>> Display application) on the iMac and Z1 respectively. Which means that if,
>> for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be
>> used as a monitor for a laptop or another computer (via Target Display
>> Mode). As far as I've been able to discover, Target Display Mode does not
>> exist under any flavor of Linux.
>> 
>> What would it take to support this in Fedora? Is this a Desktop-centric
>> feature for Gnome/KDE/Cinnamon, or is this something that would/should be
>> part of the Linux kernel itself? I don't think it's directly part of a
>> graphics driver (at least on Windows, since HP released My Display as a
>> separate program), but again I'm not sure.
> 
> You'd have to reverse engineer or ask HP/Apple what they actually do for this
> to work.
> 
> then implement that.

Or maybe Intel would be forthcoming. It's their hardware.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Anyone else using and interested in co-maintaining sogo?

[Sandro Mani]

Hi,

Needing a calendar server for the company, I've ended up packaging the 
groupware server SOGo [1], which is a neat MS Exchange alternative. SRPM 
of sogo plus deps are here:


http://smani.fedorapeople.org/review/sogo-2.0.7-1.fc21.src.rpm
http://smani.fedorapeople.org/review/sope-2.0.7-1.fc21.src.rpm
http://smani.fedorapeople.org/review/lasso-2.3.6-1.fc21.src.rpm

I think the packages are pretty decent and fit for inclusion into 
Fedora, and they might well be of interest to other people. However, I 
am hestitant to post them for review since Objective-C and GNUStep are 
not really known territory for me, and I'm also rather unexperienced 
with stuff like LDAP.


So, anyone who would like to see these in Fedora and is willing to help 
out if things go wrong?


Thanks,
Sandro


[1] http://www.sogo.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Code Hosting, Development Tools and Open Source

[Kamil Paral]

> I've been kicking this idea around for a bit and have chatted a little
> with people on IRC but as we're looking to start up development on
> taskbot, I want to have a larger discussion on two issues: where do we
> host code and what do we want to use for dev support tools (issue
> tracking, code review etc.).

My thoughts:

* We should avoid self-hosting as much as possible. If we consider something 
self-hosted, it should be far better than something managed by a third-party.

* Anonymous viewing is a must for an open-source.

* FAS integration is ideal, but not strictly necessary, if we use a widely 
popular service (like github). If we force people to create an account in our 
self-hosted service just to report a bug, we won't receive many bug reports.

As you described Phabricator, it doesn't seem to be ready yet (no anonymous 
viewing, no FAS integration). I might have misunderstood something, but were 
you considering to implement that? That doesn't sound as a few days task. If 
the two issues were not there, I'd like to give it a try, it definitely sounds 
interesting.

I like Github, but it really might be too simplified for our use cases. I 
haven't studied these advanced tasks like moving a bug report to a different 
project, but it seems you have. (On the other hand, does Trac support this 
particular task?). It might be a good idea to ask fedora-infra guys about their 
experience.

Fedorahosted + Reviewboard is far from ideal. Lately you and Martin have been 
using it the most, so I think you're the best people to say whether we want to 
stay with it or move away from it. Thanks very much for investigating this.
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Alternative to Debian origins?

[Sérgio Basto]

On Ter, 2013-10-15 at 15:19 +0200, Miroslav Suchý wrote: 
> In Debian distributions exist file:
>/etc/dpkg/origins/default
> which is symlink to
>/etc/dpkg/origins/debian
> with content:
>Vendor: Debian
>Vendor-URL: http://www.debian.org/
>Bugs: debbugs://bugs.debian.org
> 
> Do we have some alternative to this in Fedora world?
> 
> The goal of this file is to difference vendor. See:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487437
> for more details.
> Then dpkg-vendor(1) works with this information.
> 
> For example Ubuntu point the symlink to
> /etc/dpkg/origins/ubuntu with content:
> Vendor: Ubuntu
> Vendor-URL: http://www.ubuntu.com/
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Parent: Debian
> 
> I am only aware of:
>/etc/*-release
> which is not perfect equivalent.


Hi, 
I'm the current maintainer of dpkg, since other 2 are unresponsive , 
I'm consider add patch on
https://bugzilla.redhat.com/show_bug.cgi?id=973832 
for F20. 
But, now ,I'm very busy in my work , I just can read this thread and
apply patch later night or tomorrow . 

Best regards
-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Daniel P. Berrange]

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 noise.
> 
> That's the problem we even disagree how to read the numbers.  There aren't
> enough numbers (+their stats).

Well if no one can come up with a way to produce numbers that clearly
demonstrate that prelink is useful we should ditch it, regardless due
to the complexity / downsides it causes.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 tools no longer compatible with
non-zero file address base may have problems in future if someone wants to use
them that way for example on some embedded system.

But another opinion can be s/he should fix them her/himself if s/he needs such
a feature.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct