Re: [gentoo-user] Re: Shared libraries in Gentoo

[Alan McKinnon]

Apparently, though unproven, at 02:56 on Thursday 09 September 2010, Enrico 
Weigelt did opine thusly:

> * Alan McKinnon <alan.mckinnon@×××××.com> wrote:
> > > True. But FreeBSD isn't that popular like Windows, Mac or Linux.
> >
> > So you don't work at a Tier 1 ISP then?
> >
> > FreeBSD rules that space. I get hugely better performance out of Postfix
> > on FreeBSD than on Linux - all other ISPs in this country concur.
>
> Well, not everybody is a tier-1 isp ... ;-o
>
> BTW: one of my customers, a really big one here in Germany
> (who also has several of the major free mail portals) runs
> its mail systems on GNU/Linux (well, inhouse mailing is done
> via Exchange+ADS, surprisingly it actually works ;-)).
>
> But I'd really like to know what produces the performance hits
> on Posfix @ Linux.

It comes down to the IO scheduler. Linux is designed to be general purpose. 
FreeBSD is designed to be much more specific.

Both are very good at what they do, the trick is in realising what those 
things are and playing to their strengths.


> > In fact, portage is complete overkill and I refuse to allow it
> > to be deployed at work. Check my posting history for the
> > rationale behind this.
>
> Well, portage could be much thinner if certain things would be
> moved explicitly out-of-scope or solved more generic on a
> different layer. (yes, I'm explicitly ignoring the historical
> issues right now ;-p).

My beef with portage in my specific production setup is the amount of work it 
takes my guys to keep everything up to date. We don't have 150 identical 
servers in a farm (I'd love that and would switch to Gentoo immediately if it 
were). I have 130 completely different configs and uses for those servers.

The maintenance admins would have to fully grok all of portage, the 
implications, predict the outcome and understand what they are about to update 
every time they do an update. And they'd have to know it for 130 permutations.

Heck, *I* can't track that, I won't expect someone else to. Centos better 
suits our needs - deploy X, you know what you are going to get. Having said 
that, all my personal stuff and my own dev boxes are Gentoo. Why? Coz I can 
change stuff around for testing on a whim, figure out the right approach then 
document what to do on Centos to achieve that.


>
> For example:
>
> * distro-specific and various source retrieval methods would not
>   be necessary, if the packaging/distro-build system would simply
>   fetch it's sources from an vcs (eg. git ;-p) using canonical
>   versioning/namespace scheme [1].
>
> * instead of useflags (the terminology implies we're switching
>   things some package *uses*, not provides), model the available
>   features, eg. like Briegel [2] does. (that's more a methological
>   that a technical issue).
>
> * instead of slotting, assign separate package names when multiple
>   version concurrency is required (and maybe pull them together
>   via virtuals)
>
> * rely on an pure DAG as dependency graph - per definition.
>   when circular dependencies occour, fix them in the source tree,
>   for example splitting off certain packages in several smaller ones.
>
>
> [1] http://www.metux.de/download/oss-qm/normalized_repository.pdf
> [2] https://sourceforge.net/p/briegel/
>
>
> Don't get me wrong, that shall not be understood as ranting against
> Gentoo, just showing suitable approaches we'd start afresh on a
> "green grassland" (w/o all the historical burdens).
>
>
> cu

-- 
alan dot mckinnon at gmail dot com