[gentoo-user] firefox.bin vs firefox

[gentoo-user] firefox.bin vs firefox

[Harry Putnam]

Is there any advantage one way or the other emerging firefox.bin vs firefox?

Re: [gentoo-user] firefox.bin vs firefox

[Poison BL.]

On Wed, Dec 17, 2014 at 9:45 PM, Harry Putnam <reader@newsguy.com> wrote:
> Is there any advantage one way or the other emerging firefox.bin vs firefox?
>
>

There are advantages to both, really, since firefox-bin uses a
pre-built executable (with a pre-defined set of compile-time options),
while firefox builds from source, using the options defined by the
list of applicable USE flags. The tradeoff is time, heat, and
electricity in return for more options in what is (or isn't) included
and enabled.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] firefox.bin vs firefox

[Alan McKinnon]

On 18/12/2014 04:45, Harry Putnam wrote:
> Is there any advantage one way or the other emerging firefox.bin vs firefox?

Depends on your needs:

firefox:
- pro: you get all the USE flags
- pro: you don't get bundled libs from Mozilla, the ebuild can use
system libs
- pro: the compiled binaries are integrated into gentoo like other ebuilds
- con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
minutes...



firefox-bin:
- pro: fast install. It's a binary package
- con: you get all of Mozilla's bundled libs
- con: No USE, no choices. If Mozilla eg decides to ship with
pulseaudio, then that is what you must have on your end
- con: poor integration with the rest of your system. Files go where
Mozilla says they go, the devs can only do so much to make stuff standard.


As I see it, go with firefox unless you can't spend the cpu cycles to
build it locally. That's true of almost all -bin packages

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] firefox.bin vs firefox

[Alec Ten Harmsel]

On 12/17/2014 04:59 PM, Alan McKinnon wrote:
> On 18/12/2014 04:45, Harry Putnam wrote:
>> Is there any advantage one way or the other emerging firefox.bin vs firefox?
> Depends on your needs:
>
> firefox:
> - pro: you get all the USE flags
> - pro: you don't get bundled libs from Mozilla, the ebuild can use
> system libs
> - pro: the compiled binaries are integrated into gentoo like other ebuilds
> - con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
> minutes...

Really? 20-35 minutes? I have 6 cores and 32G, and firefox only takes 10
minutes. Do you have PORTAGE_TMPDIR mounted on tmpfs?

Alec

Re: [gentoo-user] firefox.bin vs firefox

[covici]

Alec Ten Harmsel <alec@alectenharmsel.com> wrote:

> 
> 
> On 12/17/2014 04:59 PM, Alan McKinnon wrote:
> > On 18/12/2014 04:45, Harry Putnam wrote:
> >> Is there any advantage one way or the other emerging firefox.bin vs firefox?
> > Depends on your needs:
> >
> > firefox:
> > - pro: you get all the USE flags
> > - pro: you don't get bundled libs from Mozilla, the ebuild can use
> > system libs
> > - pro: the compiled binaries are integrated into gentoo like other ebuilds
> > - con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
> > minutes...
> 
> Really? 20-35 minutes? I have 6 cores and 32G, and firefox only takes 10
> minutes. Do you have PORTAGE_TMPDIR mounted on tmpfs?
> 
> Alec

Mine takes more than an hour, I don't use tmpfs for /var/tmp/portage
because sometimes I need many gigs even more than memory for certain
packages.  But Linux is pretty good at disk caching, so I wonder if that
is it?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] firefox.bin vs firefox

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On Wed, 17 Dec 2014 20:59:23 -0500, covici@ccs.covici.com wrote:

> Mine takes more than an hour, I don't use tmpfs for /var/tmp/portage
> because sometimes I need many gigs even more than memory for certain
> packages.  But Linux is pretty good at disk caching, so I wonder if that
> is it?

You can change PORTAGE_TMPDIR per-package. I have it on a tmpfs and then
change it for packages like LO.

% cat /etc/portage/package.env/libreoffice 
app-office/libreoffice disk-tmpdir.conf

% cat /etc/portage/env/disk-tmpdir.conf 
PORTAGE_TMPDIR="/mnt/scratch"


-- 
Neil Bothwick

... "I just forgot to increment the counter," Tom said, nonplussed.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] firefox.bin vs firefox

[covici]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 17 Dec 2014 20:59:23 -0500, covici@ccs.covici.com wrote:
> 
> > Mine takes more than an hour, I don't use tmpfs for /var/tmp/portage
> > because sometimes I need many gigs even more than memory for certain
> > packages.  But Linux is pretty good at disk caching, so I wonder if that
> > is it?
> 
> You can change PORTAGE_TMPDIR per-package. I have it on a tmpfs and then
> change it for packages like LO.
> 
> % cat /etc/portage/package.env/libreoffice 
> app-office/libreoffice disk-tmpdir.conf
> 
> % cat /etc/portage/env/disk-tmpdir.conf 
> PORTAGE_TMPDIR="/mnt/scratch"

That is interesting, but firefox requires 8g I think of temp space, the
very package which takes so long.  I have 16g of memory, but I wonder if
my whole system would start to crawl.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] firefox.bin vs firefox

[Dale]

covici@ccs.covici.com wrote:
> Neil Bothwick <neil@digimed.co.uk> wrote:
>
>> On Wed, 17 Dec 2014 20:59:23 -0500, covici@ccs.covici.com wrote:
>>
>>> Mine takes more than an hour, I don't use tmpfs for /var/tmp/portage
>>> because sometimes I need many gigs even more than memory for certain
>>> packages.  But Linux is pretty good at disk caching, so I wonder if that
>>> is it?
>> You can change PORTAGE_TMPDIR per-package. I have it on a tmpfs and then
>> change it for packages like LO.
>>
>> % cat /etc/portage/package.env/libreoffice 
>> app-office/libreoffice disk-tmpdir.conf
>>
>> % cat /etc/portage/env/disk-tmpdir.conf 
>> PORTAGE_TMPDIR="/mnt/scratch"
> That is interesting, but firefox requires 8g I think of temp space, the
> very package which takes so long.  I have 16g of memory, but I wonder if
> my whole system would start to crawl.
>
>

I have 16Gbs here and I have portage on tmpfs.  Only once has it ran out
of room and it was slow as expected.  It was working on seamonkey,
firefox and LOo all at the same time.  Yea, it was memory hungry.  It
has only did that once during a emerge -e world tho.  It's never
happened during a normal update. 

I think setting at least LOo to not use memory would pretty much fix
this issue.  I plan to work on that at some point.  I also plan to work
on upgrading to 32Gbs too. 

Dale

:-)  :-) 

[gentoo-user] Re: firefox.bin vs firefox

[»Q«]

On Thu, 18 Dec 2014 03:59:58 -0500
covici@ccs.covici.com wrote:

> That is interesting, but firefox requires 8g I think of temp space,
> the very package which takes so long.  I have 16g of memory, but I
> wonder if my whole system would start to crawl.

I would try it.  I have only 8GiB.  I used to build firefox in RAM, when
it only required 4GiB in the tempdir, which was only a few months ago.
Then I had to switch to building on disk.  My build times went up from
~16 minutes to ~21.

Re: [gentoo-user] firefox.bin vs firefox

[Peter Humphrey]

On Thursday 18 December 2014 08:23:59 Neil Bothwick wrote:

> You can change PORTAGE_TMPDIR per-package. I have it on a tmpfs and then
> change it for packages like LO.
> 
> % cat /etc/portage/package.env/libreoffice
> app-office/libreoffice disk-tmpdir.conf
> 
> % cat /etc/portage/env/disk-tmpdir.conf
> PORTAGE_TMPDIR="/mnt/scratch"

Are comments allowed in, e.g., /etc/portage/env/disk-tmpdir.conf?

-- 
Rgds
Peter.

Re: [gentoo-user] firefox.bin vs firefox

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

On Thu, 18 Dec 2014 10:26:42 +0000, Peter Humphrey wrote:

> > % cat /etc/portage/env/disk-tmpdir.conf
> > PORTAGE_TMPDIR="/mnt/scratch"  
> 
> Are comments allowed in, e.g., /etc/portage/env/disk-tmpdir.conf?

It's just a bashrc file,so comments should be fine.


-- 
Neil Bothwick

Top Oxymorons Number 46: Found missing

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] firefox.bin vs firefox

[Peter Humphrey]

On Thursday 18 December 2014 11:53:41 Neil Bothwick wrote:
> On Thu, 18 Dec 2014 10:26:42 +0000, Peter Humphrey wrote:
> > > % cat /etc/portage/env/disk-tmpdir.conf
> > > PORTAGE_TMPDIR="/mnt/scratch"
> > 
> > Are comments allowed in, e.g., /etc/portage/env/disk-tmpdir.conf?
> 
> It's just a bashrc file,so comments should be fine.

That's good, because that's the easiest way to include or exclude things in 
it to compare the effects of tmpfs.

-- 
Rgds
Peter.

Re: [gentoo-user] firefox.bin vs firefox

[Alan McKinnon]

On 18/12/2014 03:33, Alec Ten Harmsel wrote:
> 
> On 12/17/2014 04:59 PM, Alan McKinnon wrote:
>> On 18/12/2014 04:45, Harry Putnam wrote:
>>> Is there any advantage one way or the other emerging firefox.bin vs firefox?
>> Depends on your needs:
>>
>> firefox:
>> - pro: you get all the USE flags
>> - pro: you don't get bundled libs from Mozilla, the ebuild can use
>> system libs
>> - pro: the compiled binaries are integrated into gentoo like other ebuilds
>> - con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
>> minutes...
> 
> Really? 20-35 minutes? I have 6 cores and 32G, and firefox only takes 10
> minutes. Do you have PORTAGE_TMPDIR mounted on tmpfs?



Yes, it is a tmpfs. I notice firefox compile times have been steadily
increasing over time, and also vary a lot. But, with 16G ram, I've
stopped worrying about what else the machine is doing when emerging.
I'll easily do an mp4 encode with handbrake while building firefox and
not worry about load :-)

     Sat Aug  2 14:08:00 2014 >>> www-client/firefox-31.0
       merge time: 18 minutes and 37 seconds.

     Mon Sep  1 00:08:02 2014 >>> www-client/firefox-31.0
       merge time: 13 hours, 54 minutes and 44 seconds.

     Thu Sep  4 23:53:39 2014 >>> www-client/firefox-32.0
       merge time: 19 minutes and 50 seconds.

     Sun Sep 14 10:43:15 2014 >>> www-client/firefox-32.0
       merge time: 41 minutes and 59 seconds.

     Thu Oct 16 19:50:24 2014 >>> www-client/firefox-33.0
       merge time: 34 minutes and 56 seconds.

     Fri Nov  7 20:34:48 2014 >>> www-client/firefox-33.0-r1
       merge time: 21 minutes and 13 seconds.

     Sun Dec  7 14:01:03 2014 >>> www-client/firefox-34.0.5-r1
       merge time: 37 minutes and 31 seconds.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: firefox.bin vs firefox

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On 18/12/2014 04:45, Harry Putnam wrote:
>> Is there any advantage one way or the other emerging firefox.bin vs firefox?
>
> Depends on your needs:
>
> firefox:
> - pro: you get all the USE flags
> - pro: you don't get bundled libs from Mozilla, the ebuild can use
> system libs
> - pro: the compiled binaries are integrated into gentoo like other ebuilds
> - con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
> minutes...
>
>
>
> firefox-bin:
> - pro: fast install. It's a binary package
> - con: you get all of Mozilla's bundled libs
> - con: No USE, no choices. If Mozilla eg decides to ship with
> pulseaudio, then that is what you must have on your end
> - con: poor integration with the rest of your system. Files go where
> Mozilla says they go, the devs can only do so much to make stuff standard.
>
>
> As I see it, go with firefox unless you can't spend the cpu cycles to
> build it locally. That's true of almost all -bin packages

Thanks posters... and especially this compete walk-thru.

Looks like its best to stick to the gentoo way of doing things and go
with non `bin'.

Re: [gentoo-user] Re: firefox.bin vs firefox

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Thu, Dec 18, 2014 at 01:46:45AM -0500, Harry Putnam wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> 
> > On 18/12/2014 04:45, Harry Putnam wrote:
> >> Is there any advantage one way or the other emerging firefox.bin vs firefox?
> >
> > Depends on your needs:
> > […]
> > firefox-bin:
> > […]
> > - con: poor integration with the rest of your system. Files go where
> > Mozilla says they go, the devs can only do so much to make stuff standard.
> >
> >
> > As I see it, go with firefox unless you can't spend the cpu cycles to
> > build it locally. That's true of almost all -bin packages
>
> Thanks posters... and especially this compete walk-thru.
>
> Looks like its best to stick to the gentoo way of doing things and go
> with non `bin'.

The only real problem I have with Firefox-bin (though I have no idea whether
the non-bin is any better) is that it doesn't install as many icon files,
which usually leaves me with too small an icon in KDE’s Alt-Tab switcher. I
don’t have this problem on Arch.

I once -- just for fun -- compiled Firefox on an Atom N450. This has no effect
on the loading time of 20 seconds. ^^

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

I think, therefore I am at the wrong place.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Re: firefox.bin vs firefox

[the]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/12/14 06:10, Frank Steinmetzger wrote:
> I once -- just for fun -- compiled Firefox on an Atom N450. This
> has no effect on the loading time of 20 seconds. ^^

And how long did it take?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUkqdjAAoJEK64IL1uI2hacwoIAJpTGmlC+e0EzyIDEcOJDfcK
HJtlOl7T31oAGxtz51hMko0Nj0bh4dLnDVl7KTTnwfU8VCIvotyFsHweqWx4Cn2b
jHFGou/eLD9DHFtA89xyhSQmY7ywq3SIK3ywZDmiHAOI80iMzlPfB82gTSzetVe9
+XMG2GjTZ7YZa/KcPyjAFcapUh0A7y4aYGW71XI1gqUI6nvdRJY3kGuVV1Xrw3Zc
dXgilcpjk9n/Jyj2NtxjNsZQyGQTiz5TqICkUURKg2ZxH/YJniQLGutVnJp+vnfF
q/OzH6trZ6frbKqkqeOfYrARxbrpnsO+Gz7mr7dPDr3SVyxox92+9zJTwbgpkJ0=
=0Sfj
-----END PGP SIGNATURE-----

Re: [gentoo-user] Re: firefox.bin vs firefox

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Thu, Dec 18, 2014 at 01:07:34PM +0300, the wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 18/12/14 06:10, Frank Steinmetzger wrote:
> > I once -- just for fun -- compiled Firefox on an Atom N450. This
> > has no effect on the loading time of 20 seconds. ^^
> 
> And how long did it take?

Can’t really remember, I’d have to fire the baby up in order to look (I
don’t use it productively anymore). Maybe 15–20 hours, but I could confuse
that with the compile time of LibreOffice.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

Friends may come and go, but enemies accumulate.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-user] Re: firefox.bin vs firefox

[»Q«]

On Wed, 17 Dec 2014 23:59:59 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 18/12/2014 04:45, Harry Putnam wrote:
> > Is there any advantage one way or the other emerging firefox.bin vs
> > firefox?  
> 
> Depends on your needs:
> 
> firefox:
> - pro: you get all the USE flags
> - pro: you don't get bundled libs from Mozilla, the ebuild can use
> system libs
> - pro: the compiled binaries are integrated into gentoo like other
> ebuilds
> - con: slow compiles. I have 8 i7 cores and 16G. the merge takes 20-35
> minutes...
> 
> firefox-bin:
> - pro: fast install. It's a binary package
> - con: you get all of Mozilla's bundled libs
> - con: No USE, no choices. If Mozilla eg decides to ship with
> pulseaudio, then that is what you must have on your end
> - con: poor integration with the rest of your system. Files go where
> Mozilla says they go, the devs can only do so much to make stuff
> standard.

Those are good lists.  The only thing I can think to add is that
firefox-bin is built with "Profile Guided Optimization";  the firefox
package has the pgo USE flag for that, but it's forced off because it
doesn't work and upstream doesn't support it.

Building with PGO roughly doubles compile time, as firefox has to be
built twice.  I don't know what optimization gains there are.

> As I see it, go with firefox unless you can't spend the cpu cycles to
> build it locally. That's true of almost all -bin packages

+1