Sabayon Stabiliser

The following talks about how you can gradually move Sabayon from the testing tree to the stable tree of portage.

Sabayon. Very cool. However, it is a bit disturbing that it bases everything on the testing tree of portage.

In make.conf, there is a line:

ACCEPT_KEYWORDS=~amd64

That last part may read ~x86 if you are on a 32bit platform. In gentoo speak a package is "masked" in the portage tree (the software repository) until it has completed testing. The ~x86 or ~amd64 keyword identifies a packages as being in testing. Once testing is complete, the keyword changes to "x86". Ie, without the tilda.

The line above is essentially saying that whenever you install a package, it should install the latest testing version.

This can lead to problems, as the packages in testing haven't been tested to see if they are ready for release - that they haven't been QAed to work with everything else you may have installed.

So just remove the line from make.conf right? Wrong. The dependencies that packages have on each other are far too complex for this to work. Another strategy would be to work out groups of packages that work together, and roll them back to stable using /etc/portage/package.keywords and /etc/portage/package.mask

Forget it. Portage is the tangled web we weave.

The following approach works on this principle: You accept that you currently have a bunch of testing packages installed,but everything seems to be working. Then take advantage of the fact that lots of people are volunteering their time to ensure that these packages are suitable for release, or fixing them so that they are. So if you could say "Ok, no package can be upgraded from now on until they are in the release tree".

So look at this:

equery -i list | sed 's/(.*)/\>\=$1 -~amd64 amd64/' > packages

This command will get a list all of your currently installed packages, add a ">" to the beginning of each line, and add " -~amd64 amd64" to the end of each line, and output them all to a file called "packages"

So if the package was this:

media-video/vlc-0.8.6-r1

Now it looks like this:

>media-video/vlc-0.8.6-r1 -~amd64 amd64


If this line were put into /etc/portage/package.keywords, it would be saying "remove the "~amd64" mask from this package, and add the release mask, if the version number is greater than the one shown. In other words, don't install any more test versions for this package.

So if the file you generated is added to the end of /etc/portage/keywords then any updates to these packages will not be installed unless they are in the release tree. So now, all you need to do is wait until enough packages are in release that you feel confident you can remove the ACCEPT_KEYWORDS line from make.conf.

Note that for the above file, the first line of the "packages" file will not be valid. Remove the first line. You can append the file to package.keywords with (as root):

cat packages >> /etc/portage/package.keywords

Note that this is not a fire and forget solution. There are likely to be dependency tweaks you need to make as you go along, and you will have to enter a line in package.keywords for any new packages you install, but this at least will stop "emerge world" from ensuring your system is never stable.

Windows the Boot

Yeah, Windows sucks. It is truly awful. But a necessary evil for myself and many others.

One of the suckiest things is how it refuses to accept that there can be in existence any other operating systems in the world but itself.

So I have a PC, and had a Windows and Linux install for some time running together, with grub in the MBR handling the booting both Linix and Windows. Or at least passing booting off to ntldr to bring windows up. No problem.

But then I wanted to reinstall Windows in another partition. It is always good to do a reinstall of Windows into a fresh partition so that you can copy over bits and pieces of the old install as you need them (notably stuff in the Application Data folder in your profile). So it was time. My Windows installation had gotten slow and bloated after only six months, as I randomly install software to make the experience more palatable. My new strategy was to run everything from Linux primarily, and do Windows stuff from a windows VM on my server, and just use native Windows for games.

I did try and use VM Server as a way of reinstalling Windows into the partition without having to leave Linux, by creating a partition based disk for the vm. VM Server reports that the partition table is invalid if you do this on my install. There are a few people who have experienced this before, but none seemed quite the same as mine, and I didn't get to the bottom of it.

So it was time for a native install. So a PC fairly useless while Windows gets on with copying itself. Except it didn't work. This was new - most of the problems you get with Windows I have encountered one time or another but this one I hadn't seen.

The CD would boot, and do the "Checking Hardware configuration" message that precedes the blue install screen, but it never got to the blue. It just cleared the screen and hung.

So.. a bit of a googling (sorry Google for using your name as a verb, but seriously, it is one now) and I discover that Windows XP install will not work if there is a boot sector that it doesn't know. Ie, if there is one present, and it isn't a Windows one. Either that or the partition tables aren't aligned the way it expects.

So a bit of monkeying around later - reorganising the partitions in a way that I did not want, and having to boot the disk with no hard drives connected, I finally got Windows installed. Of course my boot sector is now trashed with the Windows one instead of grub.

But clearly putting grub back is only going to give me problems next time I want to wipe windows.

The good news is that you can boot Linux - essentially chain grub - from NTLDR - the windows boot manager. There are a stack of articles about it around, and from my experience GRLDR doesn't work - this is the grub4dos boot manager that should be able to read and process a standard menu.lst file. The documentation is erratic, and says that it must on the boot drive, but cannot be on ntfs. Not sure how you resolve that if your boot drive is ntfs.

So the other way is to get a copy of the grubbed boot sector, make a file out of it, put it in the root of your boot drive, and just add it to boot.ini.

You need to understand which is your boot drive. In my case grub was installed in the MBR of the primary disk /dev/hda. After all this stuffing around, that had been wiped, so I reinstalled it into another drive:


# grub
grub> root (hd0,7)
grub> setup (hd0,7)


This will install grub into /dev/hda8 (the eighth partition of the first ide drive - grub itself numbers partitions from zero). If your first drive is SATA, then this may refer to /dev/sda

Now make a copy of the first 512 sectors:


dd if=/dev/hda8 of=linux.boot bs=512 count=1


Copy this to your primary Windows partition - wherever boot.ini resides (usually c:\). Then edit boot.ini and put in the line:


c:\linux.boot="Linux"


Reboot, and this will appear in the standard boot menu for Windows.

Sabayon

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.

Compiz XGL

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....

Screen Screen

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 %=”

Screen is the Answer

The question is "How can I make my command line life easier in linux (and other unix style os')?"

Screen is the answer, but it is the answer even if you aren't asking the question. Screen is so fundamentally useful that should be a fundamental part of the kernel if you ask me.

So what is it? So there you are, connected to your linux box, and you kick of a compile. Before you know it, there a zillion dependencies to consider and it is going to be there a while. So now your session is tied up, so if you want to get on with something else, you need to make a new connection to the box. But what if you need to restart the machine you are connecting from while a day long compile is taking place? Killing your connection to the linux server will kill any processes associated with that session.

Or what if you want to try something in one session and see the output in another session? SecureCRT is a great ssh client, and version 5 supports tabs, which is cool. But of course each time you need make a new session, you need to authenticate.

Anyway, "screen" is the answer, as you already know because I told you at the start.

What screen does is decouple the console session from the console itself. When you create an ssh session, you are providing an input/output tty. So that you can tell the box what to do, and it can talk back to you.

What screen does is provide a proxy for that session. So screen is where your input and output go to, and you can either be connected to screen or not. When you are running screen it is transparent, it is just like you are carrying out a normal session.

But if you close your ssh session, and then reconnect from another terminal, typing screen -r will let you carry on where you left off. And it doesn't matter whether that is another ssh session, or a telnet session, or if you walk up to the physical console.

So thats useful right? But this isn't all of by a long stretch. screen isn't limited to one console session. You can have a number of them. You could have 10 different sessions going to your linux box simultaneously and then disconnect them all and resume them all somewhere else.

screen is controlled with the ctrl-a meta by default, and here are a bunch of useful commands:

ctrl-a c Create and enter a new screen
ctrl-a n Switch to next screen
ctrl-a p Previous Screen
ctrl-a " List screens
ctrl-a M Monitor screen for activity (will bell other screens if something happens)
ctrl-a S Split screens
ctrl-a Tab Switch between split screens

So there is a handful, and note that you can cut and paste between screens, which makes it massively useful when on the console.

This concludes this screen article and it will now sit amongst the millions of others on the net. There is a reason why they are all there: screen is the answer.

Physics and Graphics

So.. AGEIA bring out a new idea - a year ago - where you have dedicated hardware for modelling physics. Similar reaction to when the first 3D accelerators were introduced. Who would buy specific purpose hardware where games were the only real place for them to be used. How frivolous!

Of course, the environment is different now, what with quad SLI and all, but still. Then ATI (I think) pointed out that a lot of physics calcs could be done with Shader 3.0 hardware. Graphics hardware.

Now I thought, "surely the Shader 3.0 hardware is going to be busy shading pixels?". My point being that you would have to sacrifice the dedication of the graphics hardware to do the physics. Robbing peter to pay paul as they say. I can see how putting the physics chip on a graphics card would be a winner - excepting of course the size of the bloody things already. And anyway Asus have gone ahead and made a card, and there is Physx support in games already. So it looks like it is going to happen. And why not really? Games are an entertainment medium unlike any other, and immersion is key to the enjoyment of any game after gameplay. And good graphics and physics help immensely.

But back to that ATI idea... Using Shader 3.0.

My mobo has an AGP slot, and a PCIe. I chose this because my current graphics card is AGP, and my next one will be PCIe. But ultimately, I am going to have a card that can support Shader 3.0 doing nothing once I employ a spanking new card. I mean, I cannot run them SLI for example, and I am not going to be playing games on two machines. Oh perhaps if Vista comes out and I want two windows machines and Vista is worth a damn, then it might get used I suppose. But that spare processing power can be used in the same machine.

So. My thinking is that you can open the world to hardware physics to a wealth of people by simply using their old Shader 3.0 cards to do the physics while their new card runs the graphics. It is subgenius I tell you.