Skip site navigation (1)Skip section navigation (2)
Date:      Thu,  8 Sep 2011 21:01:08 -0700 (PDT)
From:      Stefan Schaeckeler <schaecsn@gmx.net>
To:        freebsd-ports@freebsd.org
Subject:   Re: The cost of a source based package system
Message-ID:  <20110909040108.78BE01EE8F1@keeper.homelinux.org>
In-Reply-To: <201109081326.11474.erichfreebsdlist@ovitrap.com> (message from Erich Dollansky on Thu, 8 Sep 2011 13:26:11 %2B0700)
References:  <20110908045328.C6E2E1EE8F1@keeper.homelinux.org> <201109081326.11474.erichfreebsdlist@ovitrap.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi there,

 
> On Thursday 08 September 2011 11:53:28 Stefan Schaeckeler wrote:
> > Hi all, please don't take this posting too serious. I was just curious ...
> 
> your are talking about a serious problem.

Absolutely. Billions are spend on Green Computing and even PhD theses are written on it.


> > Using source based ports is with almost 5 US cents 6.19 times (case 1 vs case 2a) or 1.73 times (case 1 vs case 2b) more expensive than using binary packages :)
> 
> Yes, but:
> 

> You are moving the cost from you to the the hosting companies. If
> more people use packages, they will need more capacity to supply all
> the different variants.

A lot of variants are compile-time options, e.g. ./configure --enable-XXX. Looking at ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/, there is only one vlc binary, although vlc has a lot of variants.

Independent of that, diskspace is cheap and there are only a few package mirrors.


> Does anybody know what takes more capacity? The sources or the
>  binaries? I would believe that the sources would take more space and
> bandwidth but the different variants of the binaries could be much
> bigger at the end.

Random check, binaries are 7 times slimmer

 978427   bash-4.1.10.tbz  // binary package
6598300   bash-4.1.tar.gz  // source from ftp.gnu.org


One could optimize ports a lot more for a) download speed and b) compile time:

- downloading only a diff from the current version to the new, updated, version (that's virtually impossible for binary packages). That should save significant download time but might be difficult to implement as most software is only distributed as tar-balls.

- no 'make clean' and reusing the object files of the current version for building the new, updated, version. That should save significant compilation time. Does that work as of today?


So, in theory, ports could be made greener than packages :)

 
> I remember some articles about the electricity bill Google gets every month. It is not that low.
> 
> So, to paint a more complete picture, we must see both sides of the fence.

... and from your follow up email:

> how did you manage to get an answer from Google that fast?
>
> http://www.google.com/hostednews/afp/article/ALeqM5gK2BT8m9EhMCL0gI-yqyut3UOz-A?docId=CNG.8da7524161341a630734bbb6cf9ce6e4.231

So, Google is going green. FreeBSD ports could try to do the same :)


> To make matters worse, people like me do both. I upgrade via the packages and then compile while I am already able to work with the new ports. At least, if the packages worked.

That's bad for the environment :P


> At the end, we who want to go green have to stop using the Internet
> and go back to postal services as it costs less energy.

This contradicts your Google link: "Three days of streaming YouTube video requires as much energy as making, packaging and delivering a DVD".


@ Eitan:

> > The number of ports and binary packages varies slightly. I don't
> > know why. This only introduces a small error.
>
> Likely due to "build dependencies" which are not needed when
> installing via packages.

Bingo!

 Stefan


-- 

Scotty: Captain, we din' can reference it!
Kirk:   Analysis, Mr. Spock?
Spock:  Captain, it doesn't appear in the symbol table.
Kirk:   Then it's of external origin?
Spock:  Affirmative.
Kirk:   Mr. Sulu, go to pass two.
Sulu:   Aye aye, sir, going to pass two.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110909040108.78BE01EE8F1>