Pauls Blog

Sabayon linux is an interesting distro. It is based on Gentoo, which is a favorite of many, but seeks to eliminate some of the compilation hassle of Gentoo by providing a live CD and an installer that installs precompiled packages.

A desktop Gentoo install would be up and running in a day or so, whereas you can get Sabayon installed and running as quickly as any other distro – the install time is a function of the number of packages you install.

So how does it work in real life? Well, installation is indeed a breeze – using the mini-CD option you are up and running in no time.

The mini-CD has a subset of the full Sabayon install DVD, which comes in at 3.3 gigs. The Sabayon team say that they have eliminated all the “useless” things to make the mini version. These useless things are presumably included on the DVD.

So once you have installed, you will want to add a few of your own packages. And this is where things get interesting. Firstly Sabayon has a release schedule, and an existing Sabayon installation can be upgraded to the new release, though only those packages that are part of the distro. I would imagine this would often cause non-Sabayon packages to break.

However, if you are a happy to manage this, then install some extras. But this is where things get tangled. For example, it is recommended that an

emerge –sync
layman -S
emerge –newuse –update –deep world

is performed to get everything up to date. This is pretty important as anything you want to install over and above standard Sabayon, is likely have library version dependencies that are not met by the install disk libraries.

So what happens here in effect is that everything in standard install is almost immediately replaced by updated and recompiled versions. And something is bound to want to look at the kernel in /usr/src/linux, so you had better put one there. And build it. And then install it (thankfully Sabayon does provide the .config file for the default kernel in /proc/config.gz). But the whole point of Sabayon is to not have to do this… I had around 6 gigs of downloads once I had updated everything.

But then there is something else Sabayonic that comes into play. Sabayon states that it is cutting edge – and it is – it comes with late release nvidia and ati drivers, and aiglx, xgl and beryl are there out of the box. But in order to be cutting edge, masked packages need to be accepted.

Masked packages are flagged with ~amd64 or ~x86 depending on your architecture. These are packages that have not been fully tested and so it is up to you if you want to risk installing them.

A sabayon default installation has “ACCEPT_KEYWORDS=~amd64″ in make.conf, which means that it will emerge anything in testing. This is how it achieves cutting edge-ness. But obviously not everything in testing will work – thats the whole point of testing it. So the emerge will fail on various packages, which will cause you to try and find a path through the dependencies that will allow everything to work – by managing what goes into /etc/portage/package.mask. This is pretty difficult.

And it seems to me that it is impossible to go back to not bring in untested packages. Well, not impossible, but hard. The keyword can be switched off, but then everything needs recompilation. But some of the libraries cannot be downgraded – you are warned that downgrading will break the system – like glibc.

So anything that relies on a library that is currently in testing cannot be downgraded must by definition be an “in-testing” package. So trying to unravel the dependency web is intractable.

Having gentoo on the desktop is pretty cool, and Sabayon does a good job of getting you there – but the nature of gentoo is that you are compiled to your architecture, so having precompiled binaries doesn’t give you any of the benefits that gentoo is about – except emerge’s excellent dependency management. But that demands that you recompile everything, which then makes Sabayon redundant.

Perhaps the better approach would be to install vanilla gentoo, then use layman to bring in the sabayon overlay, and use the Sabayon part of the portage tree to bring beryl and all the extra goodies that make Sabayon worthwhile.

This took a bit of getting going, but it works now. This is on Ubuntu on a laptop with an ATI X600 onboard.

The error I was getting referred to “Support for non power of two textures missing”

This suggests that the driver I am using cannot handle anything other than square textures, and googling showed that I should be using the fglrx driver rather than the standard ati driver.

Thats great, but I was already using the fglrx driver, so something else must be afoot. I tried a bunch of things, even AIXGL, but couldn’t get passed this error – which was coming from compiz.

So I gave up and went back to X vanilla. But back in X I found that ordinary GL apps were running slow – max 5 fps.

That is when I discovered that dri – direct rendering – wasn’t being loaded. So no 3D acceleration. And it was simple enough, the composite option was enabled in xorg.conf:

Section “Extensions”
Option “Composite” “Enable”
EndSection

Composite cannot coexist with dri – and once disabled, GL apps sped up. glxgears went from 100 fps (which I actually thought wasn’t a problem – that is a high frame rate in the scheme of things) to 1400 fps.

So I fired up XGL again, and bam, my windows are now wobbling around my cubic desktop just like they should.

I hope someone else lands here and this helps….

Continuing my enthusism for screen, the terminal multiplexer (on most linux dists), I found the

following post in response to another post about the wonders of screen.

Basically, some tips for using screen within screen – which comes in handy when you want to kick something off but still have a terminal session attached to it – and you already have a screen session in play.

The deal is that the “outermost” screen hears the Ctrl-a sequence and responds to it.. so detaching from inside the second screen sessions detaches the first (you’ll understand when you start using it)…

For anyone that dislikes C-a as the command key (e.g. emacss or bash users) one of the two following keys may be convenient. Put one of these lines in a file called ~/.screenrc:

#to use C-] as the command key
escape ^]\
or

#to use C-\ as the command key
escape ^\
it’s useful to use different escape sequences on different machines so that ssh’ing from one to the other and running screen within screen doesn’t cause an aneurism.

another useful customization is to show the current screens at the bottom of the page:

hardstatus alwayslastline ” ] H]{= Bw} %w %=”

notice that that has a ] as the first character; this helps me remember which escape key I’m using at the moment. On a machine with C-\ as the escape key, it should be:

hardstatus alwayslastline ” \ H]{= Bw} %w %=”

Nircmd is a great little utility for making the Windows command line just that little bit more useful.

nircmd will let you manipulate many aspects of what is going on in your windows session, such as closing, minimising and restoring windows (even by class), stop/starting services, turning off the monitor, shutting down, even making windows varying levels of transparent.

This greatly enhances what you can accomplish with batch files without having to resort to vb or other scripting languages.