Now with 3D working quite well on my radeon (HD4650) I've tested a few games. Somewhere in the last 3 days the performance got a good kick, the improvements are noticeable.
Quake3 by default is limited to 1600x1200 and pretty much maxes out at 90fps all the time. It feels really smooth, and the resolution is quite nice too :)
UT2004 runs at 1920x1200, looks awesome, but is a bit too slow. Around 1280x1024 the performance is high enough to play well.
Nexuiz at 1920x1200 has a rather wobbly performance. Sometimes it goes down to about one frame per second, then spikes back to 30+. Around 1280x1024 it too becomes nicely playable.
That's quite awesome for an open driver, and it's about the first time I've heard the graphics card fan kick in like that.

And people were right, you really only need the -9999 versions of mesa + libdrm + xf86-video-ati.

About the portage options and all that, darkside has blogged about some in the past. It's nice to have some numbers to put next to the --jobs magic :)
And KingTaco had found the CPU hotplugging madness quite some time before me. Plus ca change, plus c'est la meme chose.

I've been slacking a bit, now I'm feeling almost guilty for letting bugs rot. It's interesting to see how motivation works. Sometimes I even wonder why I spend any time on such things - as soon as I fix a bug upstream does a new release, a security issue is found or some other form of breakage. It's a bit frustrating to see this endless stream of "work" coming in ...
But I'm quite happy to see more and more involvement from users. It's good to see people trying to help. Most seem to lack confidence, what they lack in skills they make up for in learning at an insane pace. So as long as there is someone to guide them a bit they are totally awesome. Which means that if I can get some more people motivated I can finally resume infinite slacking because I've been made redundant. I think that should be the goal of every package maintainer :)

Yesterday was my last day at NVidia. I’ve worked with the Embedded Software team there for the last 15 months, specifically on the system software for a Linux based stack that you will see some time next year. I’ve had a great time there, learning new things, and doing everything from tweaking bit-banging I²C implementations with a CRO to tracking down alleged compiler bugs (I’m looking at you -fstrict-aliasing) by wading through ARM assembly.

As some of you might already know, my next step, which has had me bouncing off the walls for the last month, is to join the great folks at Collabora Multimedia working on the PulseAudio sound server. I’ll be working from home here, in Bangalore (in your face, 1.5-hour commute!). It is incredibly exciting for me to be working with a talented bunch of folks and actively contributing to open source software as part of my work!

More updates as they happen. :)

Just installed a wireless card in the laptop I use at Laidley… the wireless card is a pretty standard Intel Pro/Wireless 2915ABG mini-PCI card. It works flawlessly under Linux. I think it was originally from an IBM Thinkpad T41, as it has “FRU: 93P4239″ which when used as a search keyword, leads me to that page on the ThinkWiki site.

I’ve used it just fine in the Toshiba TE2100 I had no problems under Linux… never did get Windows to work with it.

I gave it another try today, after installing it into the Satellite PRO 6100 that I use at Laidley… The machine runs Windows XP as Texas Instruments likes to play all kinds of ridiculous proprietary games with their DSPs and MCUs (in particular, the TMS320LF2406A and the MSP430). So I’m stuck with this horrid OS.

I popped the card in… no problems, slots in nicely under the keyboard. Windows boots up, recognises the card as being a “network controller”, but doesn’t have the drivers… so far so good. Downloaded the drivers off the Lenovo site, and also grabbed the official Intel ones.  I’ve tried both thus far.

Upon installation, I see the following:

Okay… fine… let’s see what the Event Viewer can tell me.

Rightyo… there’s a link I can look at… what does this tell me?  I give it a try…

This wireless card works out-of-the-box in Linux with no stuffing around.  Yet… Windows won’t touch it…. and people wonder why I bag Microsoft.

If anyone knows of a solution to this gem (that doesn’t involve replacing the hardware or OS) I’m all ears.

In this podcast comprookie talks about Gentoo and podcast procrastination.

LINKS:
SSH access to cvs.gentoo.org
http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml
cvs
http://www-mrsrl.stanford.edu/~brian/cvstutorial/
http://www.gentoo.org/doc/en/cvs-tutorial.xml
git
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
perl-overlay
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary
tove
http://cia.vc/stats/author/tove
Michele Beltrame
http://www.cattlegrid.info/
Kent Fredric
http://kent-fredric.fox.geek.nz/v1
Gentoo GuideXML
http://www.gentoo.org/doc/en/xml-guide.xml
Gorg
http://gentoo.neysx.org/mystuff/gorg/gorg.xml
Gentoo Tips
http://gentoo-pr.org/

irc network freenode channel #linuxcrazy

Download

So I’ve been a long time Opera user, but lately some bugs have really started to agitate me and are killing my user experience.

The first bug is Opera is unable to open certain long URL’s from the commandline, approximately if the URL is 86 characters or longer. This was fixed awhile ago in the Windows version of Opera, but it seems it never got corrected in the Linux builds. This causes me to be greatly annoyed as applications can no longer pass long URLs to Opera to be opened. Most notably in my case is links inside my email client. I click those links expecting Opera to happily open them, but all I get is no response. Manually copying and pasting links into Opera from email is a royal pain and has tempted me to try Chromium a bit more full time. I submitted a bug report about it to Opera but we will see if that changes anything. If it doesn’t get fixed soon I’ll have to switch to just maintain my sanity of clicking URLs.

The second bug is flash freezes all the time in Opera. This is incredibly annoying when I’m watching something on Hulu. The show will be playing fine and then suddenly the video will freeze, but the sound will keep playing. This doesn’t seem to occur in other browsers such as chromium or arora. Based on that, I’d assume its an Opera bug but I can’t be sure. Either way it’s quite annoying. I can’t tell if it was a recent Opera update or flash update that introduced this behavior though.

Hoping the next Opera beta/rc fixes at the least my url length problem

Well it turns out that I need more caffeine. Today I fixed the issues I had yesterday after the upgrade to B2evoltuion 3.3.2.

It turns out that PHP error logging was disabled on the server, thus I didn't get to see the error PHP was throwing. Stupid me:-/
b2evolution-3.3.2 needs PHP with ctype support, which is simply enabled with the corresponding USE-flag. The error PHP was throwing was:

[Fri Nov 20 09:57:11 2009] [error] [client 208.115.111.247] PHP Fatal error: Call to undefined function ctype_space() in /var/www/site/htdocs/inc/_core/_misc.funcs.php on line 779


The funny thing is that apparently B2evolution is not using PHP ctype support for all posts, but only some posts (ie. with URLS). Thus making debuggin all the more fun. On top of that B2evolution now prerenders pages eventhough caching is disabled. Oh the fun of debugging.

Also I had a funny problem during the upgrade of the B2evolution MySQL tables. For future reference I'll post the details here as well. The installer threw this one:

Additional information about this error:
MySQL error!
Can't create table './b2evo/#sql-7735_1.frm' (errno: 135)(Errno=1005)
Your query:
ALTER TABLE evo_items__item ENGINE=innodb


The MySQL docs lists errno 135 as no space left in the record file and suggests way to fix this here.

At first I misintepreted the proposed solution but it simply turned out that I had to change the following line in MySQL my.cnf:

innodb_data_file_path = ibdata1:10M:autoextend:max:256M


I simply had to increase max.

Now it's time to actually see what new features B2evolution 3.3.x has...

I've just bumped media-sound/amarok in the tree to 2.2.1-r1 which includes some missing deps.
Even though 2.2.1 hit the tree before the official release, I'm a few days behind in the bump and unmasking it - the mask should be out when you read this.
Unfortunately, amarok-2.2.0 and amarok-2.2.1 segfault on start when built with >=binutils-2.20 even though they have no issue starting with >=binutils-2.20 if built with a previous version of binutils - see bug #290662 for more details.
While the issue isn't solved, here is a quick workaround:

# emerge -1 =binutils-2.19.1-r1 && emerge -1 amarok && emerge -1 binutils

After a stupid MySQL mistake I got b2evolution upgraded to 3.3.2. However it seems there is some problem in the rendering code, causing rendering to suddenly stop. So far I've hunted it down to being the last part of the function render in
inc/plugins/model/_plugins.class.php (line 1295 to 1327):


1272 function render( & $content, $renderers, $format, $params, $event_prefix = 'Render' )
...
1295 foreach( $renderer_Plugins as $loop_RendererPlugin )
1296 { // Go through whole list of renders
1297 // echo ' ',$loop_RendererPlugin->code, ':';
1298
1299 #return "Test";
1300 #$this->call_method( $loop_RendererPlugin->ID, $event, $params );
1301 switch( $loop_RendererPlugin->apply_rendering )
1302 {
1303 case 'stealth':
1304 case 'always':
1305 // echo 'FORCED ';
1306 $this->call_method( $loop_RendererPlugin->ID, $event, $params );
1307 break;
1308
1309 case 'opt-out':
1310 case 'opt-in':
1311 case 'lazy':
1312 if( in_array( $loop_RendererPlugin->code, $renderers ) )
1313 { // Option is activated
1314 // echo 'OPT ';
1315 $this->call_method( $loop_RendererPlugin->ID, $event, $par ams );
1316 }
1317 // else echo 'NOOPT ';
1318 break;
1319
1320 case 'never':
1321 // echo 'NEVER ';
1322 break; // STOP, don't render, go to next renderer
1323 }
1324 }
1325
1326 return $content;
1327 }



Seems like the above code is trying to determine wether to render stuff, disabling causes some rendering glitches but at least something is being displayed. But I'm not yet sure why it actually dies.

Another testing request. Kernel 2.6.31 is planned to be stabled soon on all architectures. Hereby I now ask users on stable x86 systems to upgrade to gentoo-sources 2.6.31-r6 or vanilla-sources 2.6.31.6 and report back to me in all cases (failure or success). The other arches appreciate tests, too, but I can't speak for them. Thanks in advance.

So… qt-*-4.6.0_rc1 is now in the portage tree, masked (since its not a final release) and you can begin testing your shiny Qt applications with it.

But there’s a catch.

4.6.0_rc1 is not binary compatible with 4.6.0_beta1. [1]
This means that if you’re upgrading from 4.6.0_beta1 you have to rebuild every single app depending on qt-*, or they won’t start at all. This obviously includes all of KDE 4.

You can get portage to do that by using a command like this:
*update* it seems some shells didn’t like the old command, so I’ve updated it:

emerge -av1 $(for i in $(qlist -IC x11-libs/qt-); do equery -q d $i | grep -v 'x11-libs/qt-' | sed "s/^/=/"; done)

Note that this command assumes your system is up-to-date. If some installed packages don’t have ebuilds available for their version anymore, you’ll have to resolve that manually (probably by removing them and rerunning the command).

You’ll find equery in app-portage/gentoolkit and qlist in app-portage/portage-utils.

You don’t need to do this if you’re upgrading from Qt 4.5.3 (although you should). You’ll also be safe if you upgrade from 4.5.3 to 4.6.0 final when the time comes.

Portage will warn you about this when you upgrade qt-core to 4.6.0_rc1:

* Messages for package x11-libs/qt-core-4.6.0_rc1:

*
* Binary compatibility broke between 4.6.0_beta1 and 4.6.0_rc1.
* If you are upgrading from 4.6.0_beta1, you’ll have to
* re-emerge everything that depends on Qt.
* Use the following command:
*
* emerge -av1 $(for pkg in $(equery -q d \
* $(qlist -IC x11-libs/qt-) | grep -v “x11-libs/qt-” |
* sort -u); do echo “=$pkg”; done)
*
* YOU’VE BEEN WARNED
*

But users (my user side as well :p) tend to ignore ewarns from time to time

Happy rebuilding!

[1] http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against-previous-46/

Here's something awesome I found mostly by accident:
In recent kernels the support for hotswapping CPUs works on x86/amd64 architectures. I stumbled over it in the 2.6.32 menuconfig and couldn't wonder if it actually works. So I had a look and found this gem:

# cat /proc/interrupts | grep CPU
            CPU0       CPU1       CPU2       CPU3

Very boring, 4 processors.

echo 0 > /sys/devices/system/cpu/cpu3/online

And we just knocked out one!
We see that in dmesg:

kvm: disabling virtualization on CPU3                                                                                                                       
CPU 3 is now offline

Hmm, are you thinking what I'm thinking?

kvm: disabling virtualization on CPU2                                                                                                                       
CPU 2 is now offline                                                                                                                                        
kvm: disabling virtualization on CPU1                                                                                                                       
CPU 1 is now offline                                                                                                                                        
SMP alternatives: switching to UP code

Wheeee. I just castrated it to a single core! I actually didn't check if the kernel lets me take CPU0 offline. That would be hilarious. Anyway ...

echo  > /sys/devices/system/cpu/cpu1/online

And we just gained a CPU:

SMP alternatives: switching to SMP code                                                                                                                     
Booting processor 1 APIC 0x1 ip 0x6000                                                                                                                      
Initializing CPU#1                                                                                                                                          
Calibrating delay using timer specific routine.. 5200.20 BogoMIPS (lpj=10400418)                                                                            
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)                                                                                           
CPU: L2 Cache: 512K (64 bytes/line)                                                                                                                         
CPU 1/0x1 -> Node 0                                                                                                                                         
CPU: Physical Processor ID: 0                                                                                                                               
CPU: Processor Core ID: 1                                                                                                                                   
CPU1: AMD Phenom(tm) 9950 Quad-Core Processor stepping 03                                                                                                   
checking TSC synchronization [CPU#0 -> CPU#1]: passed.                                                                                                      
kvm: enabling virtualization on CPU1 

This is seriously wicked. Now I just need to figure out how to bolt that onto powermanagement so that the machine knocks out cores when idle and powersaves. Linux never gets boring ...

Last week before catching the H1N1 I had the chance to play around a bit with DVB-T.

Here in .dk the analog TV signal was turned off at the start of the month, and we got some new digital freeview channels. Most notably DR HD broadcasting unencrypted 720p movies in MPEG-4.

The MPEG-4 encoding can be a bit tricky since TVs from just a few years back (ie. both my Panasonic TVs) only support MPEG-2 decoding, so a lot of people had to buy new hardware MPEG-4 decoders. However not wanting yet another power consuming device I decided to solve it on the cheap (not speaking of yet another redundant remote control).

First off old DVB-T PCI cards/USB sticks should generally be able to receive DVB-T broadcasts in any encoding, including MPEG-4. I just had an old Hauppauge Nova-T DVB-T card lying around in the basement, what luck:)

I've collected a few notes here that might be helpful for others.

First figure out what kernel options you'll have to enable.

Getting the right channel list:

emerge linuxtv-dvb-apps linuxtv-dvb-firmware w_scan
w_scan -x > dvb_frequencies
dvbscan dvb_frequencies > channels.conf


Now watch the first channel with: vlc channels.conf. Note if vlc doesn't play anything you might have messed up the generation of channels.conf as I somehow managed to do the first time.

Then record the HD content:

gnutv -channels channels.conf -out file drhd.mp4 "DR HD"


Now come the not so great part, it seems like the MPEG-4 used by DR HD is not well supported in Linux or more precisely the HE-AAC audio codec.

Current stable vlc-1.0.2 seems to be slow to tune in to the programs and audio is choppy and stastistics show dropped audio frames. Upgrading to vlc-1.0.3 seems to make it tune in faster, but the audio is still choppy.

Changing the "Caching value in ms" to 1000 seems to have solved most of the stuttering problems (Preferences -> All -> Input/Codec -> Access modules -> DVB).

Current stable ffmpeg-0.5-r1 only shows 3 streams and refuses to encode:

Stream #0.0[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc
Stream #0.1[0x91f](dan): Subtitle: dvbsub
Stream #0.2[0x920](dan): Subtitle: dvbsub


However upgrading ffmpeg to 0.5_p20373, results in it detecting another 2 streams:

Stream #0.0[0x7ef]: Data: 0x0006
Stream #0.1[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc
Stream #0.2[0x911](dan): Data: 0x0011
Stream #0.3[0x91f](dan): Subtitle: dvbsub
Stream #0.4[0x920](dan): Subtitle: dvbsub


And the live ffmpeg ebuild actually detects the audio stream, but hangs when encoding:

Stream #0.0[0x7ef](dan): Subtitle: 0x0006
Stream #0.1[0x907]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 tbr, 90k tbn, 100 tbc
Stream #0.2[0x911](dan): Audio: aac, 44100 Hz, 2 channels, s16, 450 kb/s
Stream #0.3[0x91f](dan): Subtitle: dvbsub
Stream #0.4[0x920](dan): Subtitle: dvbsub


So for now I can watch DR HD on one computer, but playback on my PCH-110 is not working either as the audio codec HE-AAC seems to be unsupported too. Later on I might just install a MythTV backend and do some automatic transcoding to the troublesome devices. That is once proper HE-AAC support is in ffmpeg:-)

As documented in this bug (which mirrors an upstream bug here there's a bug in glibc 2.10 and 2.11, and this one seems to be easy to hit. Multithreaded apps "randomly" crash with "Invalid free" and other confusing errors. A hackaround is to unset or empty the environment variable "MALLOC_CHECK_". For me setting MALLOC_CHECK_="" before starting some of the affected packages seems to completely hide the error, now we can only hope that the gentoo glibc gets this patch soon.

For the rest of this post I'll only consider portage 2.2. Most options are in portage 2.1 already, but I'm a lazy bum, so I don't compare to see what's what.

You can set PORTAGE_DEFAULT_OPS in /etc/make.conf, but if you add --ask you will have trouble running emerge from a script. --ignore-default-opts disables those defaults so you can run emerge --sync in a cronjob again.

Sets are really great, --list-sets shows you which are available. Just have a look, there are some nice ones - "security", "installed", "unavailable" ... they can help streamline some tasks. I find their names quite self-explanatory.

If you want to put something into the world file without rebuilding it use --noreplace, and if you want to remove it again use --deselect.

--nospinner disables that funny rotating spinner thingy so you can save precious bandwidth when connected remotely, and --quiet hides most of the output, which can be nice if you don't want to be hypnotized by scrolling compile output. For the OCD crowd --quiet-build might be nice as it doesn't show the compile output on console, but redirects to logfiles. --changelog is neat for seeing the log messages for that update, this often shows fixed bugs or other issues you might care about. --color with a parameter y or n toggles colorized output. And of course --alphabetical. The horror of unsorted output!

Sometimes people are confused that emerge -e world tries to update packages that emerge -uND world misses. That is usually caused by build-only dependencies. --with-bdeps=y and --complete-graph are good options to modify portage behaviour.

If you're on a fast machine and in a hurry you can try to set --jobs X with a reasonable value of X. Think about memory needs and such before setting it to infinity minus one! With --keep-going it gets really easy to not have the whole process stopped on the first failed package. This is not without issues, but it avoids the --resume --skipfirst in a loop tricks. If --jobs seems to hard to calibrate to you --load-average=LOAD may help to limit it.

For the scripters --columns might be nice, it tweaks the output to be more script friendly.

Support for binary packages has grown considerably, there's support for local (-k / -K) and remote (-g / -G ) binpkg repositories. And you can --buildpkg and --buildpkgonly to create them (they are stored in PKGDIR). There's --binpkg-respect-use to only install the packages that have useflags set the same as the current configuration - it's a very powerful mechanism if you need to support Gentoo on multiple machines and don't want to compile that much.

I hope y'all enjoyed this little lesson in RTFM, there's plenty of other options to discover. Don't be afraid of the documentation, it doesn't bite and makes your life easier :)

In diesen Minuten demonstrieren (mehr oder weniger) fünftausend Schüler und Studenten auf der Spandauer Straße in Berlin. Ich war auch am Roten Rathaus, doch meine Ideen von besserer Bildung (frühzeitig, durchlässig, besser ausgestattet, kostenfrei) sprachen dort nur wenige aus. “Kritik am Bildungssystem ist immer auch Kritik am Kapitalismus!” schallt es. Man verkauft T-Shirts und protestiert, die Universitäten seien “Steigbügelhalter des neoliberalen Systems”. Ich fühle mich instrumentalisiert von den Ideologen am Mikrofon.

Ich kann mich entscheiden, im “schwarzen Block” der Autonomen, im roten Block der Kommunisten, bei den Antifaschisten oder den Antikapitalisten mitzulaufen. Dann doch lieber zur S-Bahn.

Last Friday (November 13 2009), I gave a lecture/conference titled Mozilla and its technologies in the context of the Mozilla Campus Reps program. Indeed, I am a Mozilla Campus Rep at INSA Lyon, my university.

The lecture had four parts. First of them was a classic presentation of Mozilla and Netscape history. Then, a presentation of some Mozilla projects like applications, libraries, tools and especially Mozilla Labs. The real technical part was about the Mozilla Platform (Gecko, XUL, ...). To complete, the Open Web and web standards.

Everything went well. I planned to give a 30-minute to 45-minute length lecture with 15 minutes of questions but it looks like I had a lot of things to say and I talked one hour long. Fortunately, there wasn't a lot of questions so I finished in time.
The most important is I had only good feedback which is pretty cool for a first experience !

The Mozilla campus Reps program wasn't able to send me a swag pack so I asked to Tristan Nitot (Mozilla Europe) who seemed delighted to help. Paul Rouget (Mozilla Europe too) also helped with some advices. A big thank you to both of them !

Finally, you can download my slides. You can also get the source files here. The slides have been made in latex with beamer. All this stuff is available in Creative Common Attribution 3.0 (CC-BY).
The slides aren't really verbose. They have been made only to get attention of the audience and let them follow me. I've spoke about a lot of subjects that are not even mentioned like JavaScript benchmarking, V8, FOSS work-flow... I find it more dynamic and -I hope- less boring for the audience.

It was a nice experience and I'm glad to have spread Firefox and Mozilla !

Few people take the time to actually read through the documentation, but if you have some time to spare "man make.conf" is a great read.
For example you can pre-set some CLI options like --ask or --verbose in EMERGE_DEFAULT_OPTS so you never have to type them again. Especially the FEATURES variable has some interesting bits:

buildpkg builds packages of everything
buildsyspkg builds only packages of the system set, which is awesome for recovery and doesn't take much space.

keepwork keeps the $WORKDIR and can be quite useful for debugging purposes (but not for general use)
noclean leaves even more there.
fail-clean is the opposite, it always wipes the build directories. Useful if you build on a small (but fast) disk or tmpfs.
installsources installs all the package sources to /usr/src/debug/, which can be used for debugging, but eats lots of space. Together with splitdebug it offers some really great debugging convenience.
test-fail-continue helps when you just want to have the tests run for logging purposes, but don't want the package to not be installed if tests fail. Most people won't need this.

split-elog and split-log features are quite interesting if you do logging.

Logging can be very nice to have, and portage has lots of configuration options for it.
PORTAGE_ELOG_SYSTEM defines how the log data is sent, be it through syslog, email or just to a file. Or completely custom?
And you can do combinations like PORTAGE_ELOG_SYSTEM="mail:warn,error syslog:* save".
PORTAGE_ELOG_CLASSES defines what you want to log - warnings, errors, qa warnings, everything ... it's your choice.

Of course there are lots of other configuration options:
PORTAGE_NICENESS can be useful when you don't want portage to interfere with anything else.
PORTAGE_IONICE_COMMAND needs ionice (or an equivalent tool) and can be used to make the disk activity of portage a bit less distracting. Both features may increase the time needed to install things, but will make portage more benign so you can still do things while it runs.

Also you can change almost all directories - PORTDIR, DISTDIR, PKGDIR and so on. This allows you to make portage behave a lot more like you want it (unless the defaults satisfy you already ...)

Finally I stopped slacking for long enough to fix a few bits of my desktop, and the results are grrrrrrreat.
Now I have (OpenGL!) full effects in KDE4 as opposed to the slightly less bouncy XRender-accelerated thingies before. Performance is pretty awesome (but then the HD4650 shouldn't even notice those few effects).
What you need:

~arch install (I'm not going to care to find out what minimal versions you need)
x11 overlay
a really recent kernel

And with really recent I mean "at least 2.6.32". At the time of writing that hasn't been released, so a 2.6.32-rc6 git-sources has to substitute for me. From what I've read you might have to disable framebuffer for things to work well, but as I'm usually seeing text mode for ~30 seconds every month I don't care enough to find out. I'm lazy!
In the kernel config you need to enable DRM and especially the radeon bits. Device Drivers -> Graphics -> Direct Rendering Manager is the "most important" bit there.
The following packages were suggested in a few places, I have no idea if that is the minimal set. But you'll have to unmask:

>=x11-libs/libdrm-9999
>=media-libs/mesa-9999
>=x11-base/xorg-server-9999
>=x11-proto/fixesproto-9999
>=x11-proto/xextproto-9999
>=x11-proto/xf86vidmodeproto-9999
>=x11-proto/renderproto-9999
>=x11-proto/recordproto-9999
>=x11-proto/inputproto-9999
>=x11-proto/xineramaproto-9999
>=x11-proto/bigreqsproto-9999
>=x11-proto/xf86driproto-9999
>=x11-proto/xf86dgaproto-9999
>=x11-proto/xcmiscproto-9999
>=x11-base/xorg-drivers-9999
>=x11-libs/libXext-9999
>=x11-libs/libXi-9999
>=x11-proto/xproto-9999
>=x11-libs/libX11-9999
>=x11-libs/libxcb-9999
>=x11-proto/xcb-proto-9999

Now go forth and rebuild all your shiny new packages.
If you managed to build that and reboot your new kernel things should look pretty much as before. The only "obvious" hints I've found to test are the output of glxinfo (has changed quite a bit) and that KDE4 allows me to use OpenGL now. And maybe the wobbly windows effect was a giveaway :)

I'm positively surprised that things have progressed this far, and I'm happy to finally be able to use more of my graphics card :)

EDIT: Seems that this is not the minimal set of packages and configuration needed. Some people suggested -9999 packages of mesa + libdrm + xf86-video-ati only. If that works even better :)

Lately I noticed Eclipse having some issues such as not being able to confirm certain dialogs or press certain buttons. It made Eclipse extremely annoying to use. Before I found the relatively easy fix, I was reduced to clicking the button and the pressing enter to move past the screen, not exactly a desirable scenario to perform every 5 minutes if for example your exporting jars from Eclipse.

The fix is pretty easy, just add GDK_NATIVE_WINDOWS=1 to Eclipse’s launch script.

For example, here’s my launch script:

File: /usr/local/bin/eclipse

#!/bin/sh
cd /home/ken/eclipse && GDK_NATIVE_WINDOWS=1 exec ./eclipse $@ 

So I’m still using KDE surprisingly, and actually liking it. Finally got most of my keybinds working so I can work efficiently. I found KDE’s ability to easily pass key presses to a specific window quite nifty, allowing me to easily map all my multimedia keys to work with XMMS.

I got around to installing kbluetooth yesterday and was absolutely shocked at the result. My bluetooth actually worked. This was extremely pleasant for me as I have been disappointed with bluetooth in Gentoo for a long time. I effortlessly was able to send a file over to my phone and it just worked after confirming on my phone’s end.

Still using Claws Mail for email for now until I find a better alternative one day. Kmail pulls in too many dependencies for my taste currently and it doesn’t seem to offer anything that would cause me to switch over from claws mail.

I have to say kwin’s “Present all windows” feature thats normally the upper left edge of the screen is extremely nifty. Reminds me a lot of OS X’s expose feature. Handy for when I have 50 terminals floating around and I don’t feel like alt-tabbing for the next 10 minutes searching for the correct terminal or whatever program I’m using.

Klipper has been causing some love/hate so far. While its history function is extremely nifty, I sometimes find myself copying something only to find I can’t paste it for whatever reason. I enabled the option to keep the selection/copy buffer synchronized and the annoyance seems to have disappeared for the most part.

Plasma has been a bit crashy on and off so far. Seems to be something to do with the notification area. I wouldn’t find it as annoying if my applications would rejoin the newly spawned panel instead of floating about on the workspace. NetworkManager, Opera, and Claws Mail being the most notorious for not rejoining the panel after it crashes. Of course, the ideal solution would be to fix the crashing all together. I haven’t figured out a reliable way to introduce the crash yet, so I’m hoping it will just go away on its own.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2

Title says it all. It's pretty obvious that gnome team can't currently keep up with the income of new bugs (especially a lot of unexpected 2.26 bugs) and I keep being split between my gnome duties and maintenance of various other stuff (notably freedesktop that no-one seems to care about these days). So I need one, two or more guys/gals that want to get their hands a bit dirty. If you feel up to it, just come and say hello on #gentoo-desktop, if I'm not around, probably other gnome herd members will be waiting for you .

As I previously noted, the 96.x.y and 173.x.y series had not seen any updates yet for xorg-server 1.7 compatibility, however today that has changed. They both saw updates late last night from NVIDIA and now those drivers are available in the Gentoo tree so feel free to give them a try.

The linux kernel has lots of complexity in memory management. Swap allows to go beyond the size of real memory to allow applications to use "more". But still, at some point, you might exhaust all available memory.

The next application that requests memory (usually through malloc) will cause the kernel some trouble. It can either deny the request (which often causes hilarious results in the application) or free some memory somehow. (About the hilarity: Many coders assume that a malloc will always succeed. If it doesn't you'll get interesting misbehaviour like segmentation faults. Lots of fun to debug ...)

So, how does the kernel free memory? It can't just ask some other processes to surrender some. But it can terminate processes! It's a terminally stupid idea, but it's so stupid that it often works. And the handler for that is, obviously, the out-of-memory killer.
There's a very nice bit of information hidden in /proc to tell you what the oom-killer would do if it had to run now.

/proc/$pid/oom_score

contains the current value of the process with PID $pid. You could just compare them and see who is good and who is bad. And you can adjust it - a rarely used protection, but it might just help the oom-killer to act more sanely and less psychotic.

/proc/$pid/oom_adj

That's a numerical value used as a multiplier. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process. The heuristic is quite complex, to quote:

The process to be killed in an out-of-memory situation is selected among all others
based on its badness score. This value equals the original memory size of the process
and is then updated according to its CPU time (utime + stime) and the
run time (uptime - start time). The longer it runs the smaller is the score.
Badness score is divided by the square root of the CPU time and then by
the double square root of the run time.
Swapped out tasks are killed first. Half of each child's memory size is added to
the parent's score if they do not share the same memory. Thus forking servers
are the prime candidates to be killed. Having only one 'hungry' child will make
parent less preferable than the child.

On some systems you might not ever want to have the oom-killer strike. It's just a hilariously bad idea to kill random processes. And you can even disable it:

The sysctl vm.overcommit_memory variable (also represented in /proc/sys/vm/overcommit_memory ) defines the behaviour. To summarize: 0 is default, where the kernel uses some heuristics and allows allocating more memory than available (which is what can trigger the nice OOM assassin) 1 always allows overcommit. The documentation is a bit sparse, but it seems to be tuned by vm.overcommit_ratio, which gives a percentage to overcommit (unless I misread that). And finally a value of 2 disables overcommitting and limits application memory to the size of (swap + ram*ratio). This means that worst case you'll disallow a request when there's still physical memory available, but you'll never have to trigger Mr.OOM-Killer.

What is best? That depends on what you do and how you want things to fail. overcommit_memory = 2 will cause memory allocation failures, but your machine will always be "alive". overcommit_memory = 0 might allow to allocate more memory, but you risk getting any process killed by oom. Sucks to have sshd killed on a server - maybe it's not the best idea to have a psychotic process assassin? But it's your choice, so do what you want to do :)

Decided I'd shake things up a bit this month, after keeping the same look for nearly three straight months. Thus, I present:

icons: Area o.43
gtk+: Rele (Rezlooks engine)
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: rassilon

It's grungy, but rather sleek. Surprisingly easy on the eyes, too. The lighter elements of the Rele gtk+ theme aren't overpoweringly white, but are just light enough to provide a decent contrast to the generally darker Area icons.

There's also an uncluttered version here.

I've been looking to assemble themes that are grungy, and themes that are warmer-yet-wintry. I like winter. I still have some hope that these 80 degree weeks will come to an end soon. We're almost to the middle of November. Surely we'll see gray sky, cool breezes, and maybe even rain here in SoCal at some point, right? Right? Well, if not, I can at least put it on my desktop.

As most of you know, KDE 3.5 is getting off the Gentoo train for various reasons mentioned elsewhere (in short: security, lack of upstream interest).

Some people are still using it though and they have been asking how they can keep it on their system, without emerge screaming each time they try to update world.

I’m writing this post to guide those people (you? ) on how they can achieve that.

1. Adding the kde-sunset overlay
Perhaps the most important thing you need to remember is that the ebuilds will be completely removed from the tree, so you need to add an overlay called kde-sunset to portage which contains a copy of most of them.

To add the overlay you need to have layman with git USE flag enabled:

USE="git" emerge -av layman

make sure you add the git USE flag in your package.use or make.conf

you can then use layman to install the overlay:

layman -f
layman -a kde-sunset

if this is your first time using layman, you’ll have to add the following line @ the end of your make.conf:

source /usr/local/portage/layman/make.conf

you can keep the overlay updated by running:

layman -s kde-sunset

2. KDE 3.5 is masked (this is necessary only while KDE 3.5 is still in tree)
Now we have the overlay, but until KDE 3.5 is completely wiped off the tree, there’s a mask to warn users about it.
Portage will scream about this mask each time you try to emerge so you need to unmask KDE 3.5 manually.

There are two (and a half) ways to do this:
a1) if your package.unmask is a folder, symlink the unmask file from kde-sunset to /etc/portage/package.unmask/

ln -s /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 /etc/portage/package.unmask/kde-3.5

a2) if your package.unmask is not a folder you can append the file (but you’ll have to update it manually)

cat /usr/local/portage/layman/kde-sunset/Documentation/package.unmask/kde-3.5 >> /etc/portage/package.unmask

b) if you don’t like all that, you can emerge autounmask

emerge -av autounmask

and ask it to unmask stuff for you – note that autounmask doesn’t like :slot and will only work with -version

autounmask kde-meta-3.5

3. I don’t want KDE 4 (yet)
So all is great now but portage wants to install KDE 4 when you emerge world.
This is happening because KDE 4 went stable recently and portage thinks you want to upgrade (you should btw ).
To fix this one we need to tell portage that we actually want the 3.5 version of KDE and we don’t care about 4.

we need to edit /var/lib/portage/world and add a version (or a slot) to every kde 3.5 app we have in there.

* be careful with this file *

for example, lets say that you installed kde 3.5 using the kde-meta ebuild.
if you open /var/lib/portage/world you’ll find a line saying

kde-base/kde-meta

you need to add :3.5 which is the 3.5 slot, or -3.5.10 which is the version (or both, version first) at the end. if you add the version, you’ll have to prepend a “=” as well.

the line should now read:

kde-base/kde-meta:3.5

do this for each KDE 3.5 app you have in the world file. If you’re unsure of the slot/version, use eix packagename to find it out.

4. All systems go

emerge -avDuN world

^^ this should now be clean of any KDE 4 traces and mask warnings

If you have any issues or are interested in maintaining kde-sunset, you may visit us over @ #gentoo-kde in freenode’s IRC network or drop us an email at kde _at_ gentoo _dot_ org. We’ll do our best to help you

Maybe after reading this post your KDE 3 installation will last a bit longer

Enjoy and see you w/ KDE 4 soon

Even though I'm currently sick with H1N1, also known as swine flu, this morning I was feeling well enough to write an ebuild for an interesting media app I found: Tabu Audio Player. It's an interesting player -- while it still needs some translation work into English, it's simple and has an appealing UI drawn by Cairo.

It had only a single configure option, "debug," and a very short list of dependencies, so I figured it'd be a simple ebuild to write, right?

Wrong! Turns out that after a half-hours' worth of poking at configure.ac, the package's check for --disable-debug/--enable-debug was completely broken. If you explicitly passed --disable-debug, like "-debug" in IUSE, then it would enable the debug build every time. Thanks to rej and a3li on IRC for nailing this problem down; they were really helpful.

a3li also shared his solution for the same problem in one of his packages, so I used it in my ebuild to ensure that "debug" works properly as a USE variable.

Meanwhile, I sent a bug report to upstream asking for a smarter debug check. I also asked for CFLAGS="-02" to be removed from Makefile.am, that way folks are free to use their own -O levels without having to resort to using sed on the Makefile, as I had to in the ebuild.

Speaking of which: I have an ebuild for Tabu 2.1 waiting for you in my devspace, if you'd like to try it out.

For the longest time operating systems have been able to handle swap. In short swap extends physical memory with slow diskspace so that applications can use more memory than there is available.
On most unix systems the swap is in a dedicated partition because that has the lowest overhead. Plus you don't risk running out of diskspace when you want to swap, so things are quite predictable and nice. Linux has a very nice knob you can turn to affect the swap policy. It will not avoid swapping (in some situations you will have to), but it will affect how and when swap is used. That knob is /proc/sys/vm/swappiness.

The kernel default is a value of 60. The value can be between 0 and 100 and is effectively a percentage. It is used roughly in the following way:
If all available memory is exhausted (application memory, buffers and filesystem cache) and any memory allocation is requested the kernel needs to free a few pages of memory. It can either swap out application memory or drop some filesystem cache. The "swappiness" knob affects the probability which one is chosen.
This means that at a swappiness of 0 the kernel will try to never swap out a process, and at 100 it will try to always swap out processes and keep the filesystem cache intact. So with the default, if you use more than ca. 40% of your memory for applications and the rest is used as filesystem cache it will already start swapping a bit. The hilarious result is that you may up swapping a lot with lots of memory left - think of a machine with 64GB RAM! If you try to use 32G memory you'll be in swap hell.
That default might have been good with machines with less than 256MB RAM, but with current desktops and servers it is usually not optimal.
Now you might be tempted to tune it down to 0. Avoid swap. Swap is slow. All is good?
Not quite. At 0 your machine will try to avoid swapping until the last moment. Then it will have killed all filesystem cache (so every file operation will hit the disks) and in addition to that you start swapping like a madman. The result is usually a "swap storm" that hits very sudden. At the point where you might need some performance your machine doesn't provide it and might just be unresponsive to your input for a few minutes.
The other end (a value near 100) might make sense for a file server, but then it might be cheaper to just not run extra services on a machine that is very loaded already. I don't really see a usecase for a swappiness of 100 except maybe on machines that are very memory-limited.
On my desktop I've found a swappiness of 10-20 to be the sweet spot. This means that when 80%+ of memory is used by applications the machine will start swapping, but it's a more gradual hit and not an instant kill. And because there's still some filesystem cache the responsiveness for starting new processes (like a login shell ;) ) is still high enough to allow recovery from this pessimal system state.
Still your goal for optimal performance should be to avoid swapping. Disk access is slower than RAM by a factor of 1000 or more!
I've seen servers achieve roughly double the throughput with the right swappiness value - it can avoid an expensive hardware upgrade. Of course that's not all the tuning advice I have, so if you wish to discuss that feel free to send me a mail and maybe I can prove to you that Gentoo is the fastest penguin out there ...

Maybe I should discuss the OOM killer too - most people have seen it, but few know who it is and why he goes killing processes.

Der ADAC ist schon ein lustiger Verein. Bezeichnet sich selbst als größter Fahrradfahrerclub, da als größter Verein Deutschlands eine entsprechende Menge von potenziellen Fahrradfahrern vorhanden ist. Mit derselben Begründung wäre auch eine Selbstbezeichnung als Deutschlands größte Alkoholiker- oder Prostatakrebsvereinigung denkbar. Der Schein des selbstlosen Einsatzes für die Menschheit ist ebenso ein geschicktes Marketinginstrument, denn der ADAC ist nichts anderes als ein Wirtschaftsunternehmen. Gegen Geldverdienen ist prinzipiell nichts einzuwenden, aber wenn es auf so verlogene Weise geschieht wie bei diesem Automobilclub geschieht stinkt es.

Zwei Beispiele: Zum einen die »Gelben Engel«. Verteilen so uneigennützig kleine Geschenke an im Stau steckende Menschen. Wer genug Geld bezahlt, kann seine Produkte als eben genau diese Geschenke an den Mann bringen, in Form von Produktmustern oder verdeckter Werbung. Zum anderen das eigenartige Geschäftsgebahren. Zu Beginn meiner Volljährigkeit war ich Mitglied des ADAC, bis eines Tages der Postmann eine Nachnahmesendung brachte, die ich nicht bestellt hatte. Nach der Verweigerung der Annahme frage ich beim ADAC nach, was es damit auf sich hätte. Antwort: »Das ist eine Versicherung, die wir Ihnen einfach mal anbieten wollen.« Vielleicht gibt es Menschen, die unbesehen eine unbestellte Nachnahmesendung an der Haustür bezahlen, die hätten dann eine ungewollte Versicherung. Ähnlich verfuhr der ADAC mit Atlanten. Bei Nichtgefallen soll man sich selber um die Rücksendung kümmern, andernfalls bezahlen. Für mich der Grund aus diesem Verein auszutreten.

Wer meint, ohne ADAC bei einer Panne aufgeschmissen zu sein, sollte mal einen Blick in seinen Pkw-Versicherungsvertrag werfen. Viele enthalten eine Mobilitätsgarantie, die genau diese Leistungen abdeckt, man besitzt also hier eventuell eine Doppelabdeckung. Krankenrücktransporte aus dem Ausland und ähnliche Leistungen bei der Plus-Mitgliedschaft decken andere Anbieter günstiger ab. Sei es die eigene Krankenversicherung mit einem kleinen Zusatzobulus oder separate Anbieter wie R+V bei jeder genossenschaftlichen Bank. Wer den Maltesern Geld spendet, kriegt diese Leistung sowieso obendrauf.

Wegen der stark autozentrierten und umweltpolitisch fragwürdigen Ansichten ist es sowieso ratsam, sich von diesem rückwärtsgewandten Club fernzuhalten.

Starting today, Greek Gentoo users have their own mailing list to discuss stuff and ask questions: gentoo-user-el.

For more info on how to subscribe, please visit http://www.gentoo.org/main/en/lists.xml

The list is not mentioned there yet, but you can use it normally.

[the rest of this message is in greek]

Θέλετε να συζητήσετε για το αγαπημένο σας Gentoo στα ελληνικά αλλά δεν βρίσκετε κάποια official mailing list?

Πλέον μπορείτε να χρησιμοποιείτε την νέα λίστα gentoo-user-el, που δημιουργήθηκε για να καλύψει αυτό ακριβώς το κενό.

Για να γραφτείτε, αρκεί να στείλετε ένα κενό e-mail στην διεύθυνση gentoo-user-el+subscribe _at_ lists.gentoo.org και να ακολουθήσετε τις οδηγίες.

Μπορείτε να συνομιλήσετε με άλλους χρήστες του Gentoo αλλά και με Gentoo Developers (είμαστε 6 Έλληνες) και να λύσετε κάθε πρόβλημα και απορία σας

Για περισσότερες πληροφορίες σχετικά με τις λίστες του Gentoo μπορείτε να επισκευτείτε την σελίδα http://www.gentoo.org/main/en/lists.xml

Η λίστα δεν αναφέρεται ακόμα σε αυτήν την σελίδα (πρέπει να ενημερωθεί από το κατάλληλο team), αλλά εσείς μπορείτε να γραφτείτε και να την χρησιμοποιήσετε κανονικά.

Επίσης μπορείτε να διαβάσετε το περιεχόμενο της λίστας πηγαίνοντας στην διεύθυνση http://archives.gentoo.org/gentoo-user-el/

Όπως βλέπετε εγώ έκανα την αρχή: http://archives.gentoo.org/gentoo-user-el/msg_4eb9364bded3280c9685356b9e0445d0.xml

Εάν είστε από αυτούς που προτιμούν πιο άμεση επικοινωνία, μπορείτε να επισκευτείτε το κανάλι #gentoo-el στο freenode irc network: http://java.freenode.net/index.php?channel=gentoo-el

Τα λέμε εκεί

So after some frustrations with GNOME and various applications flat out breaking, I decided I might as well give KDE4 another chance to redeem itself. Installation was fairly easy, but I was plagued by a problem from the start. I had a dock like application of unknown origin that was starting with my new KDE session. After a lot of hunting down I discovered it wasn’t a dock at all, but actually gnome-do. I had completely forgotten that gnome-do could look like a fancy dock. After sorting that out I decided to keep the dock at the top of the screen at the smallest size which autohides itself when needed.

Next up was getting all those keybinds and shortcuts sorted out. My suspend and lock laptop keys weren’t working nor was my volume keys. This was somewhat disappointing that it wasn’t automagically working, but I managed to mostly solve my issues. Input Actions under system preferences let me do the bulk of my configuration. Volume Up and Volume Down keys were recognized by KDE, so I simply bound them to the commands amixer set Master 5%+ and amixer set Master 5%+. I was surprised to find out that my suspend key was also recognized by KDE, but I needed a way to actually make it suspend. After poking around with qdbus I discovered it was relatively simple. All what was needed was binding the key to this command: /usr/bin/qdbus --system org.freedesktop.DeviceKit.Power /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Suspend. Relatively easy after poking around the qdbusviewer which let me visually stumble around dbus commands.

I then proceeded to try to bind my lock screen key, but KDE complained that the key was “unsupported” or something similar. Well, it was time to finally figure out all that acpid magic. After reading the man page and a bit of googling, I banged out a relatively simple script to lock the screen for me.

/etc/acpi/events/lock:

event=ibm/hotkey HKEY 00000080 00001002

action=/etc/acpi/actions/lock.sh

/etc/acpi/actions/lock.sh:

#!/bin/sh

export DISPLAY=":0.0"

su ken -c "/usr/bin/qdbus org.kde.krunner /ScreenSaver Lock"

logger "acpi locked screen"

Probably not the best way of doing it, but it works for now so I’m relatively happy.

Didn’t need to do much for adjusting urxvt for KDE4, just added transparency to my existing config so it would fit in. Currently using claws-mail but might try out kmail later this week. I only needed to emerge x11-themes/gtk-engines-qt to make GTK not look so hideous that the default it without styling. Would be nice if I could get some kind of on screen display for when I change the brightness with my laptop keys, I’ll have to look into that a bit later.

Thats all I can remember for now, will need to explore KDE4 a bit more to see if it can replace GNOME full time.

I finally called and cancelled my Comcast cable TV subscription this weekend.  I've been meaning to do it forever.  I can't remember the last time I was even watching TV on a regular basis, though I think it was probably around 6 months or so.  With my media center up and running so well, I generally just watch something from there or rent it on Netflix these days.

Now, the question is, what to do with all the hardware?  I have three (yes, THREE) Tivos with unlimited subscriptions.  Two of them are the klunky one-tuner first generation of the Series2 boxes, but the third is an HD Tivo, which is very nice.  I could sell them, but considering the price I shelled out (for the HD one, at least, savvy consumerism got me the first two for real cheap ... under $50 each) I hate to part with it.  I keep thinking I'll get cable again some day, and by that year sometime in the future, I'll pat myself proudly on the back and say, "way to hang on to a piece of hardware for so long!  Now go get the compressed air."

I'm cursed with the pack rat mentality, though.  I hang onto stuff far too long in the oft chance that someday, I *might* need it.  On Saturday, I woke up a little early, and as is normally the weekend routine, I get the feeling that I must turn my entire world around by 11 a.m.  This time, it was the closet in my living room which has the distinction of dedicating 85% of its storage space to electronics that I might need sometime before the next century.  The other 15% is a mix between my puzzles, dust bunnies, air, movie posters, and movie t-shirts.  I have a red t-shirt promoting "Searching for Bobby Fischer", I kid you not... I'll even take pictures to prove it.

I swear I've been carrying this collection of cables and equipment for at least ten years or so, probably ever since I haven't been living at home.  It never really bothered me that I don't use most of the technology anymore (or ever, really), you just never know when you're going to need a floppy IDE cable.  Really!  I'm all about being prepared, but for the wrong circumstances.  I can just see the day when I'll be someone's hero for helping them be able to flash the BIOS on their 15-year old Dell desktop.  I still have the floppies to put it on, too.

So, this weekend was the closet's demise.  I grabbed a bunch of plastic bags from the kitchen (the bachelor's preferred method of storage and transportation for all things non-essential) and started filling them up with stuff.  My method of deciding what to keep and what to throw out was pretty simple: if I couldn't remember the last time I used it, it gets tossed.  Normally it could be times like these that a selective memory can cause problems down the road, but I had so much junk anyway, I don't think it'll cause a problem.  Besides, the memory problems go both ways -- when I do need a new cable or piece of hardware, I can't get mad at myself because I'll have forgotten I used to own one anyway.

All in all, I filled up something like eight to twelve bags of stuff.  I don't remember how many it was, but I do recall that when I took it to the thrift store and started unloading, I had so much stuff that it took two guys to carry it all away, and one of them kept laughing because the stream was endless.  I think most of it was cables.  There were some notable things that I'd been hanging onto for a long time, "just in case," some of which were: my old Gamecube, an 8 GB IDE harddrive, my old home-theater-in-a-box speakers (which were about as powerful and had as much wattage as two light bulbs), three PCMCIA wireless cards, a few wireless USB dongles, and a slew of PCI slot brackets.  I elected to hold onto the floppy drive -- it was a sound investment in 1990, and it's a sound investment today.

That's not really the interesting part, though.  There is still all the stuff that I decided to keep because it held some kind of value, but I don't have the energy or drive to see them through the process of being sold on the secondhand market.  Nothing makes a closet grow quite like a pack rat mentality combined with the laziness of avoiding the hassle of making spare change.  I've still got my Tivos, for instance.  There's an old (now) AMD Athlon64 desktop that is pretty nice -- top of the line of about 5 years ago.  Runs really quiet, too.  Then there's a used Gateway desktop I remember I bought on Craigslist for some reason a while ago, and I've never used.  I'm holding onto that one because it came with Windows, and I might someday want *another* Windows XP Home key, so I can just use that one.  It probably wouldn't work, anyway, but hey ... hope lingers longer than logic.

I almost dragged off my original Xbox to the thrift store, too.  It hasn't been as fun as I'd hoped it would have been, and having one console (PS2) with corded controllers is enough for me.  Plus it's a bit wheezy.  Probably just needs a new fan, or harddrive.  Dunno.  I also decided to keep all my TV tuner cards, even though I never use those either ... especially now without a cable subscription.  One of them was the Plextor external USB one that has MPEG4 hardware encoding (very nice).  I think my brother wanted that one.  Maybe it'll be a nice holiday surprise, as in, I'll be surprised if I manage to make it to the post office before Christmas 2010 to mail it off.

Oh yah, and there's an MSI Mini-ITX motherboard with an Intel Atom that I'll probably never try to revive, but I hate to donate it since I still think I could get at least $20 for it somewhere.  Then there's my new Motorola RAZR phone that I used for about a week before I switched to Verizon.  That's gotta be worth something.  I've also got two MP3 players, an iPod Nano and a Sansa something, each 4 GB ... too small for me to do anything with ... but I'll hang onto them just because.  I think I still have a portable Sony Walkman cassette player, too.

In actuality, I'd like to get rid of all of the stuff, provided I can do it through a simple way ... meaning I don't have to do any work, and non-creepy people flock to my house with cash in hand.  I doubt it'd happen, but hey, if you live near Salt Lake and are interested ... drop me a line.  That's about as proactive as I'm gonna get about it.  If you ever need your BIOS flashed, too, I could probably do that as well.

1. git clone git://www.gentoo-cn.org/var/git/loongson.git

2. Don't include loongson overlay's directory directly in your PORTDIR_OVERLAY. But in your own overlay, like /usr/local/portage, create symlinks pointing to sys-devel/ and sys-libs/glibc in loongson overlay. This is because you may not want to install packages from loongson overlay in your host machine. Also you need to make sure your own overlay is the first overlay containing binutils/gcc/glibc in your PORTDIR_OVERLAYS list. You may check the value of this list using command:

portageq envvar PORTDIR_OVERLAY

3. Then, just run crossdev -t mips64el-unknown-linux-gnu. This command installed the following components on my host machine:

• linux-headers-2.6.27-r2 from portage.
• binutils-2.19.1-r1 from loongson overlay.
• gcc-4.4.2 from portage. The gcc in loongson overlay currently is just a symlink to portage gcc.
• glibc-2.9_p2009042 from loongson overlay. However if you build the toolchain now, glibc-2.10.1 will be installed instead, I just updated it.
  

I've been on a roll to clean house lately, and part of that is simplifying my hardware setup.  One thing that needs to be ripped out completely is my old server, which is getting to be a real pain to maintain.  Mostly it's just my personal stuff on there, but the ebuild packages website is also running on there right now.  Between now and Tuesday, I'm going to take it down since I'm going to be rearranging my hardware setup anyway.  I'm not going to bring the old website back online, either.  The code for the new one is almost complete, and it will use a lot less resources.  There's gonna bet lots of cool stuff on the new one: better feeds, simpler interface, new domain name and hopefully a new design as well.  Oh, and the scripts aren't dependent upon portage anymore, which is the real crutch right now.  I have to run an old version of portage (2.1.4.5) that isn't even in the tree anymore, and it's making updates painful or impossible.

The new site will also run on my dedicated Linode, where I think I've finally correctly managed the apache issues, so that means there will be less arbitrary downtime as I screw around with my box here at home.  I really hate running servers at home that other people are dependent on, because I like the freedom to change things around without affecting anyone.  Right now, the old site is so CPU intensive, that I can't move it over to the VPS.

The code for the new site is much cleaner.  The entire thing is rewritten in OOP classes to access the portage tree, which makes my job incredibly easier.  Not to mention it's a lot faster.  It'll still be a bit before I get it online, but killing it will inspire me to push it along.  I'm tired of having this thing limp around when it's just a dead albatross around my neck right now.  So, farewell.  The new one will be better.

I got woken up this morning at about 5:30 because my server's fan was so loud.  Seriously.  Actually, I think I had trouble sleeping anyway, but it was unusually noisy, and when I woke up, the first thing I thought was, "what the heck is that noise?"  The rear fan in the ATX case of my server is precariously placed, and if the elements don't align quite right, it rattles quite a bit, and that's what happened here.

This is the server that houses all my media files, so I can't really just rip it out and replace it with something else.  It has two 750 GB drives right now which make up my entire library space.

I shut the sucker down for a bit so I could pop it open and see if I could adjust the fan and blow out some of the dust in there.  While it was powered down, it was so quiet in the room, I couldn't believe it.  I forgot how much noise these things make.

Since I was already up, I decided to look into some ways to either reduce the noise pollution or find an alternative storage setup.  I've got a spare Mini-ITX system and a spare external SATA drive enclosure, so I decided to fire that up and see how good my transfer rate would be if I just used external drives with a fanless low-powered Mini-ITX.  By the time I left for work, I was in the middle of transferring a bunch of media files over to the new harddrive, so I guess I'll find out later.  But the transfer rate was at about 8 MB/s, so I think it's safe to say that it'll work out pretty nice.

I'm hoping that this setup will work in the future for my dream scenario: a quiet file server.  I figure if I can buy a few 1.5 TB harddrives, and plug them all into external SATA enclosures, then I should be good to go.

I went ahead and bought a Western Digital Green 1.5 TB harddrive this morning, too, to replace my other drives in the server.  I know the Green line of harddrives isn't the fastest of the line, but I think that, for my circumstances, it'll run just fine.  They run between 5200 and 7200 RPM.  Less speed should mean less heat, which would make me worry not as much about having it as an external drive being passively cooled.  I'm not gonna be using it as the OS, for the Mini, I'm already running that off of a 4GB USB drive, and that runs plenty fast.  The only thing it'll do is just be serving up media over the wired network.  As long as the read speed is decent, I probably won't have any complaints.

Recently I upgraded a Xen server to 3.4.1 and encountered a strange problem. I've upgraded similar servers before without any problems, but on this one the Windows XP guest complained:

# xm create /etc/xen/winxp.cfg
Using config file "/etc/xen/winxp.cfg".
Error: Domain 'winxp' does not exist.


The log files were quite sparse with information but the relevant sections of xend.log seems to be:

[2009-11-06 15:44:14 5365] WARNING (image:493) domain winxp: device model failure: pid 22777: exited with nonzero status 1; see /var/log/xen/qemu-dm-winxp.log
[2009-11-06 15:44:14 5365] WARNING (XendDomainInfo:1878) Domain has crashed: name=winxp id=20.
[2009-11-06 15:44:14 5365] ERROR (XendDomainInfo:2012) VM winxp restarting too fast (Elapsed time: 0.285470 seconds). Refusing to restart to avoid loops.


And qemu-dm-winxp.log was equally silent about details:

domid: 22
qemu: the number of cpus is 1
config qemu network with xen bridge for tap22.0 xenbr0
Watching /local/domain/0/device-model/22/logdirty/next-active
Watching /local/domain/0/device-model/22/command
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 3ef34fd1-842d-0cbd-9782-29d8d597c36b
Time offset set 0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
xs_read(/vm/3ef34fd1-842d-0cbd-9782-29d8d597c36b/log-throttling): read error
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/22/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/3ef34fd1-842d-0cbd-9782-29d8d597c36b/vncpasswd.
bind() failed


And only the last line seems to be the problem. Googling a bit turned up this link, which suggest to comment out vncunused = 0 and VOILA the Windows domain now boots again.

Please turn your KDE radio on, and make sure to increase the volume to its maximum level for this important message.

After multiple setbacks we have finally managed to stabilise KDE4 on both major desktop architectures (amd64 and x86), with other teams to follow.

For this and other reasons as discussed , those of you who still use KDE3 should be seriously considering an upgrade in the near future.

The KDE3 support is being deprecated with immediate effect. This means that ebuilds are dropping KDE3 support where they were broken, or clashing with KDE4.

If you wish to still use KDE3, and you want to help others with having KDE3 around, drop a mail to kde@gentoo.org, where we can give you commit access to the special overlay which will specifically contain only KDE3 packages.
This overlay (named kde-sunset) can be easily used via layman.

Sadly upstream is not supporting KDE3 anymore and we simply lack the manpower to keep support for both (as you might have noticed in the past few months KDE3 has become more and more rusty for which we humbly apologize).

Sorry to bring you the bad news and with hope that KDE4 will suit your needs,

Tomas Chvatal
KDE Teams substituting Lead

KUDOS to Nirbheek Chauhan and David Abbott for helping to put this announcement together and Alec Warner for proofreading it.

KDE 4.3.3 was released on Tuesday, with ebuilds instantly available to users in the main tree.

We also have KDE 4.3.1 in stable \o/

KDE 3.5 is on its way out of portage, with kde-sunset being the overlay that will (hopefully) be maintained by users still interested in it.

Finally, KDE 4.4 Beta 1 is due December 1st and you’ll find it in the kde-testing overlay as usual

Yesterday, I wanted to see if I could rip a Blu-Ray disc using my PS3.  I really want to get a BD-ROM drive, but they are so expensive still, and since I can install Linux on my PS3, I figured maybe I'd try and save myself some money and see if I could manage to get one ripped and decrypted.  It actually worked, which surprised me.  Ripping the disc was the simplest thing in the world, but the key on the movie I tried (Willy Wonka and the Chocolate Factory) was too new, and currently only AnyDVD has support for it.  I'd love to buy a copy of that, but it only runs in Windows, and it's really expensive.  Instead, I'll just have to wait for the keys to pop up eventually on the doom9 forums.

The first step, though, was getting the PS3 to run Linux.  I took the shamelessly easy way out (and I don't regret it either) and installed Xubuntu.  I won't go into details about how I got Linux on my PS3 since that's well documented.  I will say that I remember quite vividly now why I can't stand binary distros.  Bleh.

The BD filesystem is UDF.  Providing you have a recent kernel (2.6.20, I think) with UDF v2.5 support, you are good to go.  I mounted a remote share and just dumped the disc to an ISO file onto my desktop.

$ cat /media/cdrom0 > wonka.iso

That was the easy part.

The hard part was trying to get it decrypted.  I had to use Java tools (bleh) to get to the source.  There are three applications you need.  And if you hate digging through forums and using download services, then I've got direct links for yah:

• aacskeys-0.4.0c.tar.gz
• bdvmdbg-0.1.5.7z
• dumphd-0.61.tar.gz

For Gentoo, you'll need to install the JDK to build the aacskeys library and binary.  I just emerged dev-java/sun-jdk and it worked for me (I know absolutely nothing about Java, but my stabbing in the dark miraculously worked).  You'll also need a runtime environment to actually execute the stuff, and I emerged dev-java/sun-jre-bin and that worked fine, too on my amd64 box.

For aacskeys and Gentoo, you'll need to apply this patch that I cobbled together from what I found on the doom9 forums to get it to compile.  It just fixes the Java include directorys for the Makefile.

Now, I'm still a bit fuzzy about what each program does, and whether you need all of them or not, so I won't go into a lot of detail.  What you want to use, though, is the dumphd program.  But to use it, you'll need to copy the aacskeys library and a file from the bdvmdbg package as well into the path or same directory as the dumphd program.

Once you have that, you can just run dumphd.sh and it'll fire up a simple little GUI telling you if it has all the libraries it needs.  Then you just specify the source and destination, and aacskeys will see if it has a working key to access the disc.

I can't really give much more detail than that, since I'm so new to this.  Suffice it to say, if you read the accompanying README doc that comes with each one, you'll get along just fine.

It took me a long time last night to get just one disc ripped and transferred over my subnet to try it out, and by the time I managed to get it mounted (mount -o loop -t udf wonka.iso /mnt/udf) and access it, it was pretty late.  The keys I had didn't work for my disc, and I didn't want to try the whole procedure over to try another disc.

Anyway, good luck if you try it.  One thing that impressed me is how much simpler it was than I thought it'd be, but what a pain it was trying to figure out where things went wrong.  The doom9 forums are a good resource, but not exactly the best place to find clear, concise information for a beginner.  That part was frustrating.

Personally, I don't think it's worth the hassle right now, the way I did it.  I'll get a BD-ROM sooner or later so I don't have to transfer the content over the network and can instead just test it directly.  But, I started out to see if I could at least get a copy of the ISO and get the tools running all without Windows, and I can.  So, that's progress right there.

Yesterday I was faced with an Asterisk problem logging src CDR records as anonymous, when dialing anonymously from a Snom SIP phone. In this particular situation it was OK to use anonymous as callerid, but not in the CDR records.

Using something like Set(CDR(src)=12345678) doesn't work since most of the CDR records are read-only. Also using Set(CALLERID(num)=12345678) also doesn't give you the expected result for the src CDR record.

However if you set the ANI callerid you will get the expected result, like this: Set(CALLERID(ANI)=12345678).