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 50
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 deploye
I demand that Goswin von Brederlow may or may not have written...
> Joey Hess 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 chi
Joey Hess 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 jo
Josselin Mouette 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 using sh
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
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
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
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
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 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
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
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
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
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
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?
--
.''`.
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
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
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 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
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
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
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.
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 itsel
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 alre
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 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
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 (affecti
On Feb 20, Stefano Zacchiroli 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 if/how ma
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
Peter Samuelson 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 link
[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
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
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 K
34 matches
Mail list logo
