ruby 1.9.3 is released, and slackware packages are here

Ruby 1.9.3 is *finally* released. Their NEWS and ChangeLog are available.

And I have packages built for slackware-current and slackware64-current here:

ruby-1.9.3_p0-i486-1_vb.txz [MD5] [ASC]

ruby-1.9.3_p0-x86_64-1_vb.txz [MD5] [ASC]

Again, these are built on the -current development branch, so use at your own risk. :)

Take care,

Tastes in Languages: an internal dialogue

This has been a point of contention for me, ever since I have had a desire to learn a “language” other than shell scripting. Which language would be most practical, valuable, powerful, reach the most receptive audience, designed with the ideals you share, what pays the bills, etc. Some, or all, of these aspects can conflict at any given point.

As for being practical or powerful, these measurements are based on your use of the language, which vary more than there are languages, so it is a continually refining target. As I continue to learn more languages, and deepen my knowledge of others, it is evident that no one language can be the end-all. Learning their benefits and drawbacks is a large part of efficient implementation.

As for valuable, this can be in a business sense, or marketability since. For me, this is the first real point of indecision. Fortunately AND unfortunately, this measurement has a callback to another measurement, “What are the ideals and motives of the language’s design?”. Business sense can be a fuzzy option sometimes. If you are a business unit that is exclusively a Java shop, it does not mean that all glue and helpers must also be java. Inversely, just because Perl is flexible and powerful, does not mean it needs to be built into a megalithic solution. The marketability of a language though, can relate more to the individual developer.

The evolution of all the available languages comes due to varying factors and motivation, and that motivation assists greatly in the type of community and reputation that a language accrues. These are the ideals that a language is evolved with. This is the perception that can be reflected back on a developer. Like how PHP was formed by a loose group of code hackers, perl was an overly flexible parsing and report language, ruby was started by a single humble person seeking to please others. Thus is the seed that grows the community. As soon as you state what language you write in, the other person immediately conjures stereotypes to cast over you. Regardless of good or bad, it is another expression of the eight mundane concerns. If it is blame or disapproval that you seek to avoid, then you find yourself not associating with a broader audience. And seeking praise and approval, you turn in towards like minded folks to reaffirm your expressed position. This may work out just fine for many, but it does put you at a great chance of clinging to an us-and-them mentality, which can be poisonous for you and the community at large. I’m not going to expand on that greatly, you can find more insight on that, starting by reading on ingroups and outgroups

And for many, they may not be an advocate of the language they know best, but it is what has been taught abd/or what they are paid to write in. That is okay, because you can learn other languages, despite the stereotypes others cast on you from what you’ve written in. There are soon likely to be a multitude of .Net folks, regardless whether loyalist or indifferent, that need to branch out to new languages. Thankfully for the open source communities at large, these folks have fodder to learn from, and become involved with to broaden their own experience.

While I have languages that I am more comfortable with, than others, ultimately I am an advocate for being a language generalist. Determining the best tool for the job requires having a broad idea of the pros/cons of many options. Forcing a project into the box you are most familiar with, is not always the most efficient or effective approach.

Hacking on KDE: part 1

In a personal brainstorm of how to better facilitate folks that want to have an ideal hacking environment, for X. The primitives of the idea need to be figured out, and often nothing happens because you can determine “If the person has enough desire, and know how, they’ll figure it out,” and most of the time this is a fine explanation.

When it comes to a project collection like KDE, compiling it and fiddling around can be supremely easy without the bounds of package dependencies, but still manageable packages. Although, there are now a lot a projects in the KDE Software Collection, and they are all modular. Even within the Slackware community, alienBob has already updated the build process for his KDE SC 4.7 packages to be modular. With the migration from SVN to git, it has clarified some aspects of the build, but it has now made a segregated landscape of projects. If someone wants to check out a new project, the latest development in it, it seems like a hidden process.

Being agnostic of which Linux distribution I am running, if, as a developer, I want to be able to easily manage working from the git repositories of the projects, installing them, and possibly even packaging the artifacts, this is a intricate process. But thankfully, it is a describable process, therefore we can automate it.

Last night I began working on a project, tentatively named ‘kappy’. With the K App, in mind, and it is written in Python, so having a py in there seems suitable.
The source code is currently living at, or browser viewable at;a=summary

Initially it is just doing XML parsing of the projects available. Next plans are:

  • making a caching ground for cloning/updating git repositories
  • building the software
  • having user definable configurations for flags and install paths
  • making recipes, of a suite of software to build
  • having a manager to package, for a respective distribution

Update: I’ve added a bug tracker for this project

If you have feedback, feel free to send it in.

Take care,

Good Times

This year has been a nice for socializing with nerds. Attending conferences is something that can get tiresome, if the content is something you do not find interesting or stimulating. Thankfully, I have no required conferences, so I can be choosy (schedules permitting). Naturally open source and languages would top the list of places to attend.

First off, was hanging out with the KDE folks in San Francisco, CA for CampKDE – April 4,5 2011. There were a number of good talks, and a great opportunity to shake the hands of names that I have seen around, as well as meeting many new folks. The kde-promo team has a YouTube channel, that they have published all the talks and interviews to.
The talk I gave there is titled “Slackware: Quickly and Easily Manage Your KDE SC Hacking.” You can get the slides in [PDF] or [ODP], plus the videos posted on the kde-promo channel have the full talk (, as well as an interview afterwards by Wade Olson (

Next, was down to Spartanburg, SC for the SouthEast Linux Fest (SELF) – June 10-12, 2011.
This is the third year that I have attended SELF, and second time to speak, but what differentiated this year from any other speaking engagement (in the past, or distant future), was that it was a talk title “Slackware Demystified”, and none other than the founder of Slackware Linux, Patrick Volkerding was not only in attendance, but sitting on the front row! The slides from this presentation are available in [HTML] or [PDF]. Unfortunately, the videos have not been published yet. Hopefully they will actually get them published, unlike the previous two years…

Lastly … so far, was a local conference, that I did not speak at, only attended. JrubyConf – August 3-5, 2011. While I use MRI Ruby much more than JRuby, this conference was a great way to be around and hear from many brilliant folks (Like Wayne Seguin, Charles Nutter (headius), Nick Sieger, and Jim Weirich, to name a few), plus I felt that I needed to make up for missing out on RubyConf taking place in Baltimore, MD.

The KDE folks strongly encouraged making it to the DesktopSummit, which was hosted in Berling, Germany this year. While it was surely appetising to think of attending, it did not work out this time. It would have been nice to shake hands with some fellow contributors, like Eric Hameleers (alienBob). Better luck next year.

All good times, I look forward to next year, or event the rest of 2011.

Feel free to leave feedback on the talks.

Take care,

a point-and-clicky (ruby) addition, dobbage!

Some time ago, the brainstorm of a simple GUI package viewer for my Slackware desktop would be handy. While completely unnecessary, I thought it would be neat.
So what did I do? Created a project on for an application that did not exist yet, and commenced to reading the source of others with similarly simple application frameworks.

While having the project created out on github was a reminder, it was not much for encouragement, so the idea lay dormant for a while. With a free moment this past weekend, I solidified several ideas and actually sought to make headway on this task. But I will say, that having the project on github for so long, has increased the rank on Google’s search results for “dobbage” so that is a plus :)

While I am crafty with many tools/languages, my weapon of choice remains ruby. For my development time, I can get an idea prototyped very quick. At which point I can decided whether it is worth it to use another language (for performance, etc.). All that to say, dobbage is written in Ruby.

Initially, I had thought that ruby-gtk2 would be the windowing toolkit to use, but then Qt and QtRuby are included in the stock Slackware installation.
I must say, there is not an abundance of applications to find, that are written in QtRuby, the bindings to access the Qt libraries is very nice and extensive. This is my first “GUI” application, so it’s all new to me. The Qt API documentation is written for C++, but once you get the hang of translating their C++ explanation to a Ruby implementation, then it’s all gravy! :)

Dobbage only has one dependency, that is not included in a stock Slackware install, and that is my slack-utils ruby library, which can be built as an installable Slackware package, or available as a rubygem. slack-utils does provide several command line tools, but more importantly, it includes a library for a Slackware Linux harness.

Right now, dobbage only shows information for packages currently installed, and for “removed” packages. Removed packages include previous iterations of upgraded packages. There is a little fancy-ness in the status bar too. Other ideas include the ability:

  • sorting the Removed packages by date removed, instead of alphabetical
  • to open an installable Slackware package (a *.t?z archive), and get a tab with information about that package.
  • to have a tab for fetching information from a Slackware repository /mirror
  • good ideas from others :)

In any event, the code is available at and here are a few screen shots.

Take care,

Getting started with compiling Wii apps in Linux

First off, setting up a development environment, and then the ability to run the games on the Wii are very different. Since my Wii was on the latest official system upgrade (v4.3), there were not many options for getting a custom game boot loader on it. Thankfully, I went with the Indiana Pwns and it was super easy and straight forward. Now I have the Homebrew Loader installed by way of using the BootMii installer, and I am free to load my own compiled projects as well.

To get the development kit up and operational it involved a bit of guess work, but thankful I can still use my GNU C utilities.

From the “devkitPPC” directory, you’ll need the appropriate download for you host type. For me, it was devkitPPC_r21-x86_64-linux.tar.bz2

It extracts to ”devkitPPC/”. You can put this where every you’d like, but I kept everything as my limited privilege user, and created a directory $HOME/bin/opt/, and put the directory there. Next you’ll need to set a couple of ENV variables that most projects look for in their Makefile’s. In my $HOME/.bashrc I added

export DEVKITPPC=$HOME/bin/opt/devkitPPC/

The manpath is for me :)

From the portlibs folder you’ll need everything with “ppc” in the name. The Wii’s proccesor is an IBM PowerPC chipset

Once you have all of these downloaded, a simple for loop will do well.

mkdir ${DEVKITPPC}/portlibs

for file in *ppc.tar.bz2 ; do tar -C ${DEVKITPPC}/portlibs/ -xjf $file ; done

Next, download libogc-src-*.tar.bz2 from, and lets get it compiled and installed (also, it depends on the ENV variables and the libraries above). The make install below will put it in $DEVKITPPC.

mkdir libogc ; tar -C libogc -xjf libogrc-src-*.tar.bz2 ; cd libogc

make clean && make && make install

Lastly, getting libfat present and respectable. get the libfat-ogc-*.tar.bz2 tar ball

tar -C ${DEVKITPPC}/portlibs/ -xjf libfat-ogc-*.tar.bz2

cp ${DEVKITPPC}/portlibs/lib/wii/libfat.a ${DEVKITPPC}/portlibs/lib/libfat.a

At this point there is enough present to begin hacking or least compiling as a tester. To validate we have a good compiling ENV, lets try out libwiigui . It is a great framework to learn/use/get started with, but for now if we use it to a validation test. At the time of writing this, the latest was So:

mkdir libwiigui ; cd libwiigui ; unzip ../

make clean && make

You should be left with two  new files (libwiigui-demo.elf and libwiigui-demo.dol).

On the SD card that I keep my HomeBrew applications on, I make a directory sd://apps/libwiigui/ and copy these two files into that directory, and rename them boot.elf and boot.dol respectively.

Now when I put the SD card in the Wii and launch the HomeBrew loader, I have a blank button (because I didn’t take the time to add icons and descriptions), and when clicked and loaded, there it the basic libwiigui framework app!


Take care,


p.s. here are a couple of additional information links.

using the new rpm2tgz, with flags!!

In slackware-current as of 2010-02-23,  the traditional command used for very basic archive conversion of RPMs into a TAR’d.Gzip’d archive, just got a hint of flare. :)

Normal usage is typically for easily converting an RPM that you’d like to review, like a ‘src’ RPM.

But you may find yourself saying, if I could just quickly/easily install <xyz>.rpm on my system as slackware package, it would make life a bit easier. Well now there are several flags available, to be used AT YOUR OWN RISK 😉

If you execute rpm2tgz with no arguments, it will output the following

$ rpm2tgz 
/usr/bin/rpm2tgz:  Converts RPM format to standard GNU tar + GNU zip format.
            (view converted packages with "less", install and remove
            with "installpkg", "removepkg", "pkgtool", or manually
            with "tar")

Usage:      /usr/bin/rpm2tgz [OPTION] 
            (Outputs "file.tgz")

  -s    extract the install scripts to /usr/doc/$PRGNAM-$VERSION/
          for review.
  -S    extracts the install scripts to be executed on package installation
          (only pre-install and post-install scripts used)
          USE WITH CAUTION! 
  -n    name the output package using the rpm's metadata
  -r    extract what the rpm's "requires" (dependencies)
          as documention to /usr/doc/$PRGNAM-$VERSION/
  -d    attempt a wellformed slack-desc from the rpm meta data

Everything is pretty straight forward on what it does, but lets have an example. Say you want hulu-desktop, so you download a file called “huludesktop-x86_64.rpm”, and with traditional usage of rpm2tgz, you would have a resulting archive named “huludesktop-x86_64.tgz”. This is fine if you are not going to install it, but if you do plan on installing this archive, now it does not conform to the naming convention.

With the flags available, you can specify the following command

$ sudo rpm2tgz -srdn huludesktop-x86_64.rpm

and get a resulting package called “huludesktop-0.9.7-x86_64-1.tgz”.

All flags are not needed, for every situation, and particular ones should be used with care (-S), which can and may frequently wreak havoc on your system.

Take care,


gnucash latest unstable

just a quick bump that i have uploaded my latest slackware builds of gnucash to cardinal

it will still all the dependencies. and now can use libdbi (for database storage), and webkit (for rendering reports). such as it is, i have compiled these in with these builds.

enjoy and take care,


linux and the Broadcom STA wireless driver

on the recent release of the 2.6.32 series kernel in the slackware-current branch, currently, it has posed a bit of a minor frustration on this Dell mini 9″ and its broadcom 4312

vbatts@mini:~$ lspci | grep Network
03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)

appearantly in the kernel headers, the definition of schedule() has moved around a little. Using the drivers downloaded from here (currently version, if you are getting an error like

vbatts@current:~/bcm1$ make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make[1]: Entering directory `/usr/src/linux-'
  LD      /home/vbatts/bcm1/built-in.o
  CC [M]  /home/vbatts/bcm1/src/wl/sys/wl_linux.o
/home/vbatts/bcm1/src/wl/sys/wl_linux.c: In function 'wl_free':
/home/vbatts/bcm1/src/wl/sys/wl_linux.c:705: error: implicit declaration of function 'schedule'
make[2]: *** [/home/vbatts/bcm1/src/wl/sys/wl_linux.o] Error 1
make[1]: *** [_module_/home/vbatts/bcm1] Error 2
make[1]: Leaving directory `/usr/src/linux-'
make: *** [all] Error 2

then the following patch will just add include the needed headers to move you along in compiling your wl.ko module

cat ../hybrid_sta-2.3.32.patch | patch -p1

at which point you should be gravy to proceed as usual.

vbatts@current:~/bcm2$ make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make[1]: Entering directory `/usr/src/linux-'
LD      /home/vbatts/bcm2/built-in.o
CC [M]  /home/vbatts/bcm2/src/wl/sys/wl_linux.o
CC [M]  /home/vbatts/bcm2/src/wl/sys/wl_iw.o
CC [M]  /home/vbatts/bcm2/src/shared/linux_osl.o
LD [M]  /home/vbatts/bcm2/wl.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /home/vbatts/bcm2/wl.o
see include/linux/module.h for more information
CC      /home/vbatts/bcm2/wl.mod.o
LD [M]  /home/vbatts/bcm2/wl.ko
make[1]: Leaving directory `/usr/src/linux-'
vbatts@current:~/bcm2$ ls
Makefile  Module.symvers  built-in.o  lib/  modules.order  src/  wl.ko  wl.mod.c  wl.mod.o  wl.o
vbatts@current:~/bcm2$ sudo mv wl.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/
vbatts@current:~/bcm2$ sudo depmod -a
vbatts@current:~/bcm2$ sudo modprobe wl

and do not forget to `unset ARCH` before compiling 😉

Take care,


kde-4.3.2 and koffice-2.0.83, for slackware{,64}-current

sorry for the short post, but see