Gentoo

Jeremy Fowler JFowler at westrope.com
Sat Jan 6 21:05:19 CST 2007


> Yet the performance and space requirements aren't 
> significantly different given today's hardware capabilities.  
> The main advantage is the knowledge that you've tweaked that 
> last microsecond out out of the system.  

Well, the performance could be quite significant when using gcc options
that utilize a processor's latest and greatest instruction sets.
Utilizing SSE, SSE2, SSE3, MMX, 3D-Now, etc.. can greatly increase a
application's performance. When SSE4 processors come down the pipe, you
can bet as soon as gcc is patched to make use of the instructions,
Gentoo will be there with a new gcc ebuild. It will be masked until its
thoroughly tested, but it will be there for all to try out. Then there
is compiling all your packages to utilize the latest 64-bit processors.
How many Distros out there are fully AMDx64? How much longer do you have
to wait for an x64 package update to be available?
 
> You don't actually build it yourself, from the original 
> source tarball.  99% of the people who run Gentoo simply do 
> "emerge <package>".  That doesn't require, or generate any 
> knowledge that "urpmi <package>" doesn't.  If the package in 
> portage is screwed up, it's no different than if an RPM has a 
> problem - most people wait for the fix to be packaged and distributed.

Actually you do. Downloading the source tarball, patching, configuring,
building and installing is exactly what emerge <package> does. It builds
from source using your system specific option specified in make.conf and
/etc/portage. Learning what those options can do and experimenting with
your system is a very educational experience and a lot of fun.
 
> Binary distros are getting better and better at updating and 
> backporting, but the price you pay with Gentoo is that you 
> have to spend significant time every few days updating 
> everything, and you have to constantly tweak and check 
> things, work out the bugs when they change something like the 
> init system or devfs, or just do clean installs like you 
> would with another distro.

...and you don't have to update packages every few days on any other
distro? There are bug fixes and security patches released for hundreds
of applications every week. If you just let your system go stale and not
do any updating, you are just asking for trouble. Those problems you
mention are not just specific to Gentoo. Anytime you change something on
any system you run the risk of breaking something else. That is just a
law of life.
 
> As far as Gentoo breaking your system or bringing you down 
> with a broken package, if that package is part of the base 
> system it sure will.  I've seen more than one system knocked 
> off-line by a failed update to part of the networking system. 
>  Once you're off-line, it's a real challenge to fix.  

How is that possible? Portage will only install a package after its been
built completely and without errors. If the new package is acting up,
just remove it (emerge -C <package>) and reinstall the old one (emerge
=<package>.<version>).
 
> I've only once had a problem with an RPM killing something by 
> not handling the config files correctly.  They intelligently 
> save existing and new config files by default.  Gentoo 
> requires intervention for EACH updated config file if you're 
> not going to risk something taking you off line.

Gentoo never writes over any protected config files. The new config file
is saved and left for you to decide what to do with it. That is exactly
what the etc-update tool is for. It scans for new config files, compares
them to the old ones, auto merges the simple little changes and give you
a list of config files it can't automerge. You then use etc-update to
display the differences, and either delete the new config, replace the
old one with the new, or merge the two together. That utility is a huge
time saver when having to merge in changes to config files.
 


More information about the Kclug mailing list