Package: www.debian.org
Tags: security
Severity: wishlist
X-debbugs-cc: debian-...@lists.debian.org,debian-devel@lists.debian.org,
rho...@deb.at
> "GF" == Gerfried Fuchs writes:
GF> Hi!
GF> * [2010-02-22 18:12:46 CET]:
>> Do mention secur...@debian.org on http://www.debian.org/security
On Feb 23, Jonathan Nieder wrote:
> The usual i386-centric reason: the PIC version is (~5%) slower than
> the non-PIC version. See PACKAGERS in the source, section 4.1.
> I considered doing this only on i386, but since I only have an i386 to
> test on, I would worry about missing packaging bugs.
Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> Using non-PIC code for a 5% speed up looks like an acceptable trade off
> to me, but it really must be restricted only to architectures which
> need it.
Those who worry about a 5% speedup should use amd64. Which is an
architecture t
Jaunā izsoles veikala atklāšana jau 18. februārī! Reģistrējies
www.ebid.lv un saņem dāvanā divas likmes bez maksas! Iepazīsties ar izsoles
precēm jau tagad un izmēģini veiksmi – varbūt esi vienīgais solītājs! Ja
izsoles laikā neatrodies pie datora, lieliska iespēja
On Feb 23, Josselin Mouette wrote:
> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> > Using non-PIC code for a 5% speed up looks like an acceptable trade off
> > to me, but it really must be restricted only to architectures which
> > need it.
> Those who worry about a 5% speedu
Package: wnpp
Severity: wishlist
Owner: "d.haley"
* Package name: liblemon1
Version : 1.1.1
Upstream Author : Egervary Research Group on Combinatorial Optimization
(EGRES)
* URL : http://lemon.cs.elte.hu/
* License : Boost 1.0
Programming Lang: C++
Descr
On Tue, Feb 23, 2010 at 04:01:51PM +0100, Marco d'Itri wrote:
> On Feb 23, Josselin Mouette wrote:
>
> > Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
> > > Using non-PIC code for a 5% speed up looks like an acceptable trade off
> > > to me, but it really must be restricted only
Thomas Weber wrote:
>>> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit :
Using non-PIC code for a 5% speed up looks like an acceptable trade off
to me, but it really must be restricted only to architectures which
need it.
[...]
> You have x86 hardware that is so old th
On Feb 23, Thomas Weber wrote:
> You have x86 hardware that is so old that it doesn't run amd64, but at
> the same moment you care about speed?
Why should I not care about speed if the hardware is slow?
Anyway, there are often good reasons to use x86 on modern hardware
(think about laptops and sm
On Tue, Feb 23, 2010 at 2:35 AM, Fuentes, Adolfo
wrote:
> Hello Raju.
>
> is a link in "/etc/alternatives" to "/usr/bin/gfortran".
Ok, thanks.
>
> When typing "gfortran -v" the options are:
>
> ]$ gfortran -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure
On Feb 23, Jonathan Nieder wrote:
> In this case the speed difference from using non-PIC code is
> noticeable. But the memory pressure from not sharing code between
> processes might mean it is not worth it --- I am really torn.
If the programs are linked statically then they will have the same
Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit :
> Anyway, there are often good reasons to use x86 on modern hardware
> (think about laptops and smaller VPSes).
You mean, like saving memory?
Wait… wouldn’t you save more memory by using shared libraries and PIC
code?
--
.''`.
Package: wnpp
Severity: wishlist
Owner: Matthijs Kooijman
* Package name: openttd-opensfx
Version : 0.2.1
Upstream Author : Various
* URL : http://dev.openttdcoop.org/projects/opengfx
* License : Creative Commons Sampling Plus
Description : a free sound s
Hi!
On Tue, 2010-02-23 at 17:14:00 +1100, Robert Collins wrote:
> On Tue, 2010-02-23 at 05:20 +0100, Guillem Jover wrote:
> > I don't think this would be worth it, as Marco has also said, if the
> > system is hosed but you can still get to the point of obtaining a
> > package to install you might
Marco d'Itri wrote:
> If the programs are linked statically then they will have the same
> memory footprint of programs linked with non-PIC libraries, so the
> situation will not be worse in this sense.
On non-i386 architectures, I will turn on --enable-dynamic to link to
the current PIC library.
Thomas Weber wrote:
> You have x86 hardware that is so old that it doesn't run amd64, but at
> the same moment you care about speed?
It's not particularly hard to find new hardware with 32 bit Atom chips
in it. There's this whole "netbook" thing..
--
see shy jo
signature.asc
Description: Digit
On Tue, Feb 23, 2010 at 08:32:09PM +0100, Marco d'Itri wrote:
> On Feb 23, Thomas Weber wrote:
>
> > You have x86 hardware that is so old that it doesn't run amd64, but at
> > the same moment you care about speed?
> Why should I not care about speed if the hardware is slow?
That you care persona
On Tue, Feb 23, 2010 at 04:45:22PM -0500, Joey Hess wrote:
> Thomas Weber wrote:
> > You have x86 hardware that is so old that it doesn't run amd64, but at
> > the same moment you care about speed?
>
> It's not particularly hard to find new hardware with 32 bit Atom chips
> in it. There's this who
Thomas Weber writes:
> And sorry, you don't care about speed if you still run *that* old
> hardware, otherwise you would have upgraded. (I bought my current
> desktop used and it is already able to run amd64).
Surely this is exactly opposite: speed matters much more on older hardware
that runs s
Josselin Mouette wrote:
> Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit :
>> Anyway, there are often good reasons to use x86 on modern hardware
>> (think about laptops and smaller VPSes).
>
> You mean, like saving memory?
>
> Wait… wouldn’t you save more memory by using shared lib
Thomas Weber wrote:
> Right, and following Wikipedia, they are clocked at 2GHz at most. I have
> some problem understanding someone who buys such a system and at the
> same time cares about 5% speed difference.
If my netbook takes 5% longer, then yes, I do care because that means it
has run at a b
Hi Russ,
Russ Allbery wrote:
> That being said, a 5% performance gain from using statically linked
> non-PIC code doesn't strike me as very compelling even for older systems.
Thank you for your candor; even a hunch like this one is the sort of thing
I was interested to hear.
I got the 6-7% diff
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-core-sounds
Version : 1.4.17
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : CC-BY-SA
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-extra-sounds
Version : 1.4.10
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : [*]
* P
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Tzafrir Cohen
* Package Name: asterisk-moh-opsound
Version : 2.03
Upstream Author : Digium Inc.
* URL : http://downloads.asterisk.org/pub/telephony/sounds
* License : CC-BY-SA-3
Hi,
I've released sbuild version 0.60.0, which has been uploaded to
unstable and is also available from
git://git.debian.org/git/buildd-tools/sbuild
(tag release/sbuild-0.60.0).
Quite a number of people contributed to this release, and their
individual contributions are in the shortlog, below.
Jonathan Nieder writes:
> Russ Allbery wrote:
>> That being said, a 5% performance gain from using statically linked
>> non-PIC code doesn't strike me as very compelling even for older systems.
> Thank you for your candor; even a hunch like this one is the sort of thing
> I was interested to hea
Roger Leigh (23/02/2010):
> 1) sbuild no longer defaults the distribution to "unstable", and
> requires setting by hand with --distribution unless configured in
> .sbuildrc. This is to prevent accidental uploads to the wrong
> distribution.
Yay. :D
> 2) sbuild now lists all p
Russ Allbery wrote:
[... explanation of the tradeoffs snipped ...]
> Note, btw, that for some algorithms, you might gain significant speed,
> more than the PIC difference, by being able to compile for more capable
> processors (enabling SSE2 can make a huge difference, for instance).
> Shared libr
29 matches
Mail list logo
