Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

I wrote: >in GCC 6 IIRC and *still* pertinent in GCC 8 and I believe 9, Still present in (sid/amd64): • gcc-8 (= 8.3.0-19) • gcc-9 (= 9.1.0-10) • gcc-snapshot (= 1:20190719-1) >>I'm currently compiling e2fsprogs with LTO for Debian --- and I'm >>seriously considering ditching that change. The

Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

>We just had SuSE embracing LTO Not entirely. With my DD hat doffed and wearing the mksh upstream developer hat, I’ve been asking the package maintainers of mksh in all distributions to remove the LTO flags, and will remove the built-in support for using LTO in the next release. Why? mksh’s tes

Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

rised in > http://blog.regehr.org/archives/1180 that Ian pointed to. But since I > last asked in 2016 we have more pedantic compiler settings and more CI - > and LTO, as much as compilers have improved on that, does not need to be > applied everywhere. Any change in opinion? I'm cu

And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

Steffen Möller writes ("And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?"): > We just had SuSE embracing LTO > (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html). > I am

And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

in 2016 we have more pedantic compiler settings and more CI - and LTO, as much as compilers have improved on that, does not need to be applied everywhere. Any change in opinion? Steffen On 30.03.16 17:22, Ian Jackson wrote: > Steffen Möller writes ("-flto to become more of a routine - an

Re: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

On Thu, Aug 04, 2016 at 07:32:54AM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 04 Aug 2016, Holger Levsen wrote: > > On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote: > > [...] > > > > 2) When unpackaging the orig.tar.gz translating binary data to > > > > text format and

Re: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

On Thu, 04 Aug 2016, Holger Levsen wrote: > On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote: > [...] > > > 2) When unpackaging the orig.tar.gz translating binary data to > > > text format and recompress using xz the tarball is "only" 265MB. > > > The transformation process

Re: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote: > my remarks about the size of this package and the explicite request to > discuss it here might have been remain unseen at the end of this ITP so > I'm hereby making some more noise. thanks for that! [...] > > 2) When unpackaging

Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

Hi, my remarks about the size of this package and the explicite request to discuss it here might have been remain unseen at the end of this ITP so I'm hereby making some more noise. Please raise your concerns about the size and your opinion about the alternatives I suggested below. In par

Re: -flto to become more of a routine - any change in opinion since 2011?

Steffen Möller writes ("-flto to become more of a routine - any change in opinion since 2011?"): > I admit to be a fan of link time optimisation and would like to see this > challenge promoted towards more of a routine challenge to establish for > our packages. I found this

Re: -flto to become more of a routine - any change in opinion since 2011?

Hallo, * Konstantin Demin [Wed, Mar 30 2016, 09:14:20AM]: > 1. LTO object format is not stable and ABI-persistent: e.g., LTO > objects compiled with gcc 5.2 may not work when using gcc 5.3 > (versions are just for example). Ref: gcc doc. > 2. Slim LTO objects are usable only with GCC of same versio

Re: -flto to become more of a routine - any change in opinion since 2011?

1. LTO object format is not stable and ABI-persistent: e.g., LTO objects compiled with gcc 5.2 may not work when using gcc 5.3 (versions are just for example). Ref: gcc doc. 2. Slim LTO objects are usable only with GCC of same version (see above). To provide wider support, you'll need to ship fat L

Re: -flto to become more of a routine - any change in opinion since 2011?

On Tue, Mar 29, 2016 at 10:27:20PM +0200, Jakub Wilk wrote: > * Steffen Möller , 2016-03-29, 16:27: > >I admit to be a fan of link time optimisation and would like to see this > >challenge promoted towards more of a routine challenge to establish for > >our packages. > > gcc-5 manpage says: "Link-

Re: -flto to become more of a routine - any change in opinion since 2011?

* Steffen Möller , 2016-03-29, 16:27: I admit to be a fan of link time optimisation and would like to see this challenge promoted towards more of a routine challenge to establish for our packages. gcc-5 manpage says: "Link-time optimization does not work well with generation of debugging info

Re: -flto to become more of a routine - any change in opinion since 2011?

On Tue, Mar 29, 2016 at 09:02:13AM -0700, Josh Triplett wrote: > Steffen Möller wrote: > > I admit to be a fan of link time optimisation and would like to see this > > challenge promoted towards more of a routine challenge to establish for > > our packages. I found this informative thread > > > > h

Re: -flto to become more of a routine - any change in opinion since 2011?

Steffen Möller wrote: > I admit to be a fan of link time optimisation and would like to see this > challenge promoted towards more of a routine challenge to establish for > our packages. I found this informative thread > > https://lists.debian.org/debian-devel/2011/06/msg00181.html > > that in part

Re: -flto to become more of a routine - any change in opinion since 2011?

On Mar 29, Steffen Möller wrote: > Spending most of my Debian time with scientific packages, I see a gain > of speed on those routines as particularly rewarding. And this may also > be a feature that would attract many to our platform as an extra > advantage over the regular self-built or downloa

-flto to become more of a routine - any change in opinion since 2011?

Hello, I admit to be a fan of link time optimisation and would like to see this challenge promoted towards more of a routine challenge to establish for our packages. I found this informative thread https://lists.debian.org/debian-devel/2011/06/msg00181.html that in particular sees the challenge

Temporary work-around (for modprobe spamming syslog; request for another opinion)

On Mon, Jun 30, 2008 at 01:35:21AM +0300, Sami Liedes wrote: > Of course I might be mistaken and there is a better solution, one that > does not involve modifying or configuring every application, > recompiling the kernel, or doing extreme things like deleting the > module. It has been suggested t

Opinion

If you can't see html part please click next link : http://trc1.emv2.com/I?a=A9X7CqopB,fj8Qctu6bu3YDkfg

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > Oleg Verych <[EMAIL PROTECTED]> writes: > > Message-ID: <[EMAIL PROTECTED]> > > WWW: > The problem with this theory (basically, that glibc is taking a > performance penalty by

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Gabor Gombas <[EMAIL PROTECTED]> writes: > Looking at the links there is no mention what "memory size" means here. > Is it the amount of RAM mapped, or the amount of memory dirtied? > Mapping more memory is less important (unless you're running out of > address space of course). Dirtying more memo

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > The problem with this theory (basically, that glibc is taking a > performance penalty by giving memory back to the system and hence being > more space efficient) is that not only is Hoard significantly faster than > glibc for OpenLDAP

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Steinar H Gunderson <[EMAIL PROTECTED]> writes: > On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: >> The problem with this theory (basically, that glibc is taking a >> performance penalty by giving memory back to the system and hence being >> more space efficient) is that not only is

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > The problem with this theory (basically, that glibc is taking a > performance penalty by giving memory back to the system and hence being > more space efficient) is that not only is Hoard significantly faster than > glibc for OpenLDAP,

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Oleg Verych <[EMAIL PROTECTED]> writes: > Message-ID: <[EMAIL PROTECTED]> > WWW: The problem with this theory (basically, that glibc is taking a performance penalty by giving memory back to the system and hence being more space efficient)

(glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

* From: Russ Allbery * Date: Sun, 24 Jun 2007 22:36:21 -0700 * Organization: The Eyrie > > Bernd Zeimetz <[EMAIL PROTECTED]> writes: [] > >> there're also the google perftools[1], which are suppsed to work very >> well and we have libgoogle-perftools in Debian. > > Hoard is noticably better for Ope

Re: [OT] Your opinion about...

On 10/15/06, Bill Allombert <[EMAIL PROTECTED]> wrote: > I have been reading about Dunc Tank. I did it because I'm seeing lots > of messages of disgusting, lots of packages have been orphaned, and > blog entries that have a kind of upset, too. > > I would be glad if you give me your opinions abou

Re: [OT] Your opinion about...

> I have been reading about Dunc Tank. I did it because I'm seeing lots > of messages of disgusting, lots of packages have been orphaned, and > blog entries that have a kind of upset, too. > > I would be glad if you give me your opinions about Dunc Tank, or > whatever is causing problems. I think

[OT] Your opinion about...

Hi *, I have been reading about Dunc Tank. I did it because I'm seeing lots of messages of disgusting, lots of packages have been orphaned, and blog entries that have a kind of upset, too. I would be glad if you give me your opinions about Dunc Tank, or whatever is causing problems. I think Du

Re: Help offered 2 - opinion wanted about debian.org

more those that fail to render correctly when I manually increase the font size.) Thanks to the maintainers of the present site. They do an excellent job! Just my opinion, Johannes NB: This doesn't mean that the pages cannot be improved. I guess one could add to the documentation and introd

Re: Help offered 2 - opinion wanted about debian.org

Hi, I personally dislike the colors of this particular website and I like cooler colors. The problem is that, I think this way and many may think alike (or not) but IMHO a color scheme is just too subjective to  ask a person's opinion.-- Luis"All science is either physics or stamp

Re: Help offered 2 - opinion wanted about debian.org

HXC wrote: I would like to help with the debian.org website. I have a bachelor degree in communication management. Is there help needed and if so where do I start / who do I contact? Grtz. HXC I also wondered what the community finds about the colours and layout used for the website Does