Hi!
On Mon, 2010-02-22 at 22:51:55 -0800, Don Armstrong wrote:
I don't have any objections to this, but I'd strongly suggest that
this get a run-through experimental with an announcement on
-devel-announce to request testing so that any really bad problems are
caught before it gets deployed
Hi!
As no opposing arguments were brought up I went ahead and now both
changes are in dpkg's git tree.
On Sat, 2010-02-20 at 00:15:10 +0100, Guillem Jover wrote:
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504
Josselin Mouette j...@debian.org writes:
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
Joey Hess jo...@debian.org writes:
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
I demand that Goswin von Brederlow may or may not have written...
Joey Hess jo...@debian.org writes:
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
On Feb 23, Jonathan Nieder jrnie...@gmail.com 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
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
On Feb 23, Josselin Mouette j...@debian.org 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
On Tue, Feb 23, 2010 at 04:01:51PM +0100, Marco d'Itri wrote:
On Feb 23, Josselin Mouette j...@debian.org 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
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 that it doesn't
On Feb 23, Thomas Weber thomas.weber.m...@gmail.com 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
On Feb 23, Jonathan Nieder jrnie...@gmail.com 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
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?
--
.''`.
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 as
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: Digital
On Tue, Feb 23, 2010 at 08:32:09PM +0100, Marco d'Itri wrote:
On Feb 23, Thomas Weber thomas.weber.m...@gmail.com 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?
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 whole
Thomas Weber thomas.weber.m...@gmail.com 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
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 libraries
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
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%
Jonathan Nieder jrnie...@gmail.com 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
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
On Sat, 2010-02-20 at 10:07:45 +0100, Stefano Zacchiroli wrote:
On Sat, Feb 20, 2010 at 12:15:10AM +0100, Guillem Jover wrote:
Second, I'd like to switch from statically to dynamically linking
against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
and libselinux (affecting
On Sat, 2010-02-20 at 00:15:10 +0100, Guillem Jover wrote:
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
160 KiB in share/doc/ and liblzma2 304 KiB, 124 KiB in share/doc/)
Regarding xz-utils' size, I
Guillem Jover wrote:
Regarding xz-utils' size, I was just checking and it seems not all
programs are linking against liblzma, by passing --enable-dynamic to
both configure lines the package gets reduced to 396 KiB. Also by
not shipping xzdec and lzmadec the package gets down to 324 KiB.
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 as well just obtain the broken files.
Of course you might have it already
On Sat, 20 Feb 2010, Guillem Jover wrote:
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
[...]
Second, I'd like to switch from statically to dynamically linking
against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
and libselinux (affecting dpkg itself
On Sat, Feb 20, 2010 at 12:15:10AM +0100, Guillem Jover wrote:
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
160 KiB in share/doc/ and liblzma2 304 KiB, 124 KiB in share/doc/) but
This just seems the
On Feb 20, Stefano Zacchiroli z...@debian.org wrote:
I've seen this for other safety-critical tools, e.g. the dar backup tool
which comes both as dar and dar-static. I personally don't believe
there would be *much* use of dpkg-static, but having it around for a
release would enable to see
Hi!
As I'd like to change some Pre-Depends in dpkg, I'm bringing this up
here for discussion, as per policy §3.5 and given dpkg “Essential: yes”
nature.
First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
160
Guillem Jover wrote:
It's one of the few native packages (if not the only one) that is still
statically linking.
dpkg appears to be dynamically linked on my unstable/amd64 box:
kee...@keegan:~$ file /usr/bin/dpkg
/usr/bin/dpkg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically
[Keegan Quinn]
Guillem Jover wrote:
It's one of the few native packages (if not the only one) that is still
statically linking.
dpkg appears to be dynamically linked on my unstable/amd64 box:
It is dynamically linked to some libraries, staticly linked to others.
Guillem is proposing to
Peter Samuelson pe...@p12n.org writes:
[Keegan Quinn]
Guillem Jover wrote:
It's one of the few native packages (if not the only one) that is still
statically linking.
dpkg appears to be dynamically linked on my unstable/amd64 box:
It is dynamically linked to some libraries, staticly
34 matches
Mail list logo
