2009 May » The Blog From Hell

I haz a luverly box of media

May 312009

This post is the happy conclusion of one heck of a weekend. I worked extremely hard all weekend trying dozens of options for buildig a media box. With no exceptions, they sucked. GeexBox was terrible. Mythbuntu was okay but MythTV was terrible. Piren sucked.
Ultimately though – I decided to try XBMC – it was awesome, but the live version was a bit limited.

So I installed it inside Ubuntu Jaunty. It is gorgeous, and I even have my WIImote working as a mouse to control it.

So here is the setup and the steps involved:
I built it out of the old parts of my computer from before it’s last upgrade, it’s an AMD Sempron single core machine with 2Gb of RAM and a 300gb hard-drive, about 200Gb filled with video files.
The name of this new box: andysandimas.
All I added to it was a WIFI card and an NVidia video card (for TV-out support).
I used my LCD secondary monitor from my main desktop to do the initial setups with however – since it is just not fun to do real work on a TV-screen.

So I started by just installing plain old Ubuntu from the Jaunty live CD – then I installed the wiimote software as per this document, and XBMC as per this one.
All pretty straight forward. I did however uninstall NetworkManager and install WICD instead because having to type my password to unlock the keystore to connect to my WPA network everytime I booted was just… not on for this case.
Then I wrote two little scripts in my home directory. The first is to get the wiimote running at bootup, it just requires a quick press on the scan button (note for those having trouble like I did: the new wiimotes don’t go discoverable by pressing 1 and 2 but instead has a little red button next to the battery-casing to enable USB).
Here is the content of wiimote.sh
#!/bin/bash wminput -d -r -w -c ir_ptr 00:1F:C5:7B:81:D8 &
This tells the wiimote input system to run as a daemon, reconnect if it loses signal, and wait indefinitely for a connection – nice for having it there all the time. Though I do need to rescan from the wiimote after reboots.
The second script is for starting XBMC, this is my launchxbmc.sh script:
#!/bin/bash export XBMC_HOME=/usr/share/xbmc xbmc -fs

Both scripts are set up to be run from startup applications. I also enabled the ssh server so I can get in remotely to do tweaks.
One seriously annoying thing I encountered with this now near perfect setup is Ubuntu’s notifications for updates: which would pop up when it found them – then de-fullscreen XBMC – despite me trying to watch a movie.
So I set that to autodownload them, and only check every two weeks.

Basically there is still a full ubuntu desktop running behind XBMC – easy to reach by just exiting the application, and this means adding things like xmame later to really expand the box’s usefullness is remarkably easy.

Share|

ZFS support in Nietzsche

Diary 2 Responses »

May 282009

Johan Hartzenberg put in a request to add ZFS-FUSE support in Kongoni. This is a rather complex topic so I felt I should write a post to clarify the status on this request and the degree to which it can be done.
I won’t bother with an explanation of what ZFS is, if you don’t know – chances are you are not the right target audience for this post anyway. Just file it under “AJ was geeking out again”

Now the first catch is this: ZFS is under SUN’s CDDL license, the same license used for OpenOffice.org. This license is FSF approved (so in adding it we don’t risk breaking our FSF compliance rules) but it is not unfortunately compatible with the GPL. This means that at this stage there is no reasonable expectation that we’ll see ZFS support in the kernel. The only Linux support for it currently available is as a fuse plugin.

This plugin is a direct port of the ZFS driver as used in OpenSolaris and the current version is compatible up to the latest ZFS in OS10 so it’s all good in that regard. However that means one small catch: there is no feasible way to put the root filesystem on a fuse-filesystem unless you use a (very clever) initrd which would probably need to be custom-built for the specific setup.
So the short answer: for the foreseeable future, you will not be able to use a ZFS root filesystem. You may be able to put almost all your system on a zpool however – but this may well require some clever post-install hacking on your part. If you really want to you could even clone your normal root into a zpool, have a bootscript mount it and chroot – so you only use the non-ZFS root for getting the ZFS root accessed.
This is completely doable but will require a bit of hand-hacking, the closest I will come to trying to support it is to post a howto if somebody writes it.

So what support do we have ? Well for starters we now have a port for zfs-fuse in the ports tree. This can be installed quite easily. The only real catch is this: it has a daemon and like all daemons in slackware likes, execution at boot-time is controlled by the executable bit, and this is unset by default. So if you want to make zfs available at boottime, you need to: chmod +x /etc/rc.d/rc.zfs-fuse

Currently it’s just about the last thing on the bootlist that will get started, edit /etc/rc.d/rc.M if you want to move it earlier (but make sure it’s after rc.fuse itself).

So that means you can manually add it to kongoni and at least create and access zpools. What about support in live ? Well I would like to add support for zfs into Nietzsce, gparted has the ability to work with it (apparently) so you should be able to create zpools during the installation phase.
The next phase gets tricker, zfs does not use the same kind of mounting that other filesystems use – instead the mountpoints are set up right inside the filesystem itself. More-over, during the installation your mountpoint needs to be under /newroot – if you wish to install to it, but it cannot be there post-install – it has to move one level up.

I don’t have a feasable way to deal with this yet – so my feeling is that adding it to the live-cd at all is a bad move. I will experiment with it a bit and I may change my mind about this, especially if the ZFS experts are willing to put in some effort to help me work out the quirks so the installer can correctly mount them – install – and then move them, or whatever methodology works) – but from my point of view, having the port is a great thing, trying to add support to set up zpools during install – especially since we cannot use it for / is just not currently doable.
I will happily accept a patch to the installer code to make it work, but I don’t feel up to doing it myself.

If anybody does feel like giving it a shot, e-mail me and I’ll send you the instructions for working on the installer and testing your code and once it works, send me the patch you created – I’ll include it if I can.

Share|

Kongoni gets it’s second desktop port

Diary 2 Responses »

May 272009

If one thing has stood out from the forum discussions on kongoni.co.za it is this: people are running it on netbooks. We have multiple reports on ASUS eeePC’s and other netbook platforms… hence my decision to add a port set for LXDE.
Lightweight X11 Desktop Environment is a low-cpu, low-ram and low-power using desktop environment designed specifically for netbooks. It is at the heart of ubuntu’s netbook remix for example.
Now there is a kongoni port. The port itself was made by adapting Eric Hameleers’ slackbuild scripts, which were very good and really didn’t need much changes to become proper kongoni ports. I did however update the versions to latest available where that had changed.
I also added a metaport called kongoni_lxde_desktop which will make sure you get the whole set including dependencies with everything, then simply select it as your session from the KDM login screen.
Please note that this is a new set of ports and should be deemed experimental, some problems have already surfaced (icons don’t seem to all be right) but it does work quite well and lxlauncher is there if you would like an eeePC like interface.

Please do try it, and help us make it even better.
Will we be doing an official LXDE based ISO ? Well, just like any other non-KDE desktop: no I won’t but I will help anybody else who would like to.

Share|

In memory of a departed friend

Diary No Responses »

May 262009

In December 2003 OpenLab ran a cybercafe on thin-client technology for the inaugural Idlelo conference. While I was manning the post, a man walked in with an air of confident self-assurance rarely found among the programming maturity where shy withdrawn or excessive exuberance tend to be more the norm.
We were quickly talking and immediately gelled as I spoke about our technologies and his questions showed a keen interest in how the system worked and performed – the interest of a true geek.
“May I put it to the test ?” he asked, and I nodded – slightly worried but well aware that my very reputation was at stake.

In a matter of seconds, he coded a fork-bomb and ran it, when my server hadn’t crashed after nearly 5 minutes of it, he declared “that will do”.

That man, was Guido Sohne and this was our first meeting. Since Guido lived far away, we didn’t see each other often, but we did meet up at many conferences and always took time for a chat, his work with FOSSFA and other FOSS organizations in Africa would grow to be legendary.
He was one of our few true geeks at heart, as much concerned with the social impact of his actions as the code he loved. We could spend hours debating – but it was always a good humored debate.

Today, reading the announcement that Africa has established an open-source fellowship in memory of him, was the first I heard that he had passed away almost 2 weeks ago. Of course, our friendship was one of the online world – so that I didn’t get the news right away is hardly surprising.
Nonetheless, it came as a shock since Guido was still very young and in my experience of him lived a surprisingly healthy lifestyle for a geek.
Still, these things do happen – and this fellowship is perhaps the most fitting memoir that could be given to Guido for his work on the open-source side of things. That he was equally concerned with the free-software side is also worth remembering.
He dedicated his life to this movement, and he will be sorely missed. Africa and our fledgling FOSS movement is far poorer for having lost him.

Share|

The Nietzsche TODO list.

Diary No Responses »

May 252009

At this stage, most of what needs to happen before we can release Nietzsche has become clear to us, so I decided to make a small change from the usual and write up the TODO list on my blog rather than a task list, I’ll keep updating this post as we go along – thus allowing others to see how we’re doing.

If you know of something I overlooked in the bugthread or have a suggestion to make – please feel free to post it in the comments.

Task:	Status:
BUG: Possible bug in reiserfs support	Confirmed – no bug.
BUG: Post-install dolphin still looks for the kongoni user’s home directory	Not started
Add support for lzma and bzip2 slackware packages	Completed: 2009/05/25
Replace mozilla-firefox with GNU IceCat	IceCat port creation complete. Kongoni port modified to remove mozilla-firefox if present. IceCat added to early ISO preparation
Replace favorites menu item for firefox with IceCat in ISO’s	Awaiting completion of above
Update to include latest ports	First run completed without major hiccups, more to follow as we get closer.
Add support for XFS and JFS	Installer: Done Kernel: Done
BUG: USB sticks fail in LIVE mode	Confirmed, need to find fix
Mask K3B from upstream ports tree until KDE4 version available	Not Started
Keyboard type selection during install	Still discussing if we should
vi symlink in default install	Done in image partitions
Finish harbourmaster	Design fairly finalized, actual complete code may not be available until post-release
Updated kernel-sources package	Done – we now have a clean upgrade for 2.6.29.4 – this kernel does not support LIVE mode however.
Improved default sudoers config, allow full access for wheel group and put default user in this group	Not started>
Modify PIG to use sudo for removing packages if possible	Not started
Modularize installer interface to allow for non-KDE/text-only installer	Done, now busy debugging it.
Modularize bootloader installation to allow for future alternate bootloader support	Done – only lilo is there, but the door is open to add others later
GRUB support	Only if somebody else volunteers the port/installer module
Missing files in “Just install mode”	Need to fix
Proxy setting wizard in KISS	Not started
Update version files	Not started
Autoremove list of packages for kongoni_remaster to clean up build-only deps when building ISO’s	Not started
Add mp3 and DVD support to main ISO	RMS approved. Will be in ports tree, also in ISO if space allows.
ZFS support	Port is in the tree and working, will be added to Nietsche. GParted seems to support zfs-fuse so it will be possible to create zpools during install I think, will need to add mount support for it to the installer. Will not be possible to use it as the root filesystem at this stage.

All in all – a very feasible list which we should get through in a not-too-huge time.

Share|

Future-proofing kongoni

Diary 2 Responses »

May 252009

So the last couple of days in between a crisis at work, I spent my kongoni time on future-proofing the system. While the only promise with 1.12.2 is to be compatible with 12.2 – taking some steps to remain forward compatible with slackware-current reduces our difficulties in future.

The first step was to engage in a process with the portpkg developers to get portpkg to support the new tbz and txz package formats. This support is working as of the most recent CVS version, I then ported our kongoni specific patches forward onto it – and thus came a new kongoni portpkg release.

Along with this I backported from slackware-current sources two ports for pkgtools and xz, these are required for the same reason – to support the new package formats.

I then did some testing and confirmed – that with these packages it is now possible once more to sync and then update kongoni’s slackware/bluewhite64 parts to current.
A further interesting result is that these were slackware64-current sources – and they built right on kongoni 1.12.2.
The slackware64-current sources believe /usr/lib will be a symlink to /usr/lib64 – while kongoni has it the other way around on 64-bit (as per bluewhite64) but they ports/packages clearly cope quite well with this difference anyway.
This means that the change-over to slackware64 when we start 2.13.0 development will be a lot easier than I expected.
In fact it should already be possible to edit your /etc/portpkg/local.conf and change the value of UPSTREAM from “bluewhite64″ to “slackware64″ as well as DIST_TARGET to “current” – and then update kongoni to be synchronized with slackware64-current rather than bluewhite64.

This is however a completely untested configuration and could break spectacularly – it will become a future default, but this will only be after the release of stable. The important thing is that those users who wish to track current can now once more do so on kongoni for both 32-bit and 64-bit platforms.

These ports are new code on kongoni though – so please test and report if anything doesn’t work, this is alpha code on an alpha release, so if it breaks, well you were warned.

Share|

Labours of love

Diary 1 Response »

May 222009

In June 2005 I was involved with the Creative Commons South Africa launch with my old friend Heather Ford. My personal contribution was techie – providing an cybercafe and wireless to the conference goers but it was great to be at this historic event and get to meet and greet such notable people in the free culture field as Larry Lessig and Nathan the crazy art guy.

During the course of the many discussions, the following conversation took place which has stuck with me ever since is to me a truly powerful explanation of one fundamental reason why free software is often better than proprietary even when it’s a small project without many eyeball effects or any great resources.

The editor of the Mail and Guardian was giving a talk about this traditional newspaper’s attempt at getting journalistic blogging by the public integrated into their online services and ultimately getting the best of traditional journalism combined with this (at the time still new and radical) concept of citizen-journalism. He repeatedly spoke about the difference between amateur and professional journalism (the former being the warbloggers).
Nathan stood up eventually and complained: “What I write is well researched, it is top quality work better than much of at is in the newspapers. Don’t call me an ‘amateur’”.
Then Claudio Prado stood up. Claudio worked for the Brazilian ministry of culture and was there representing Gilberto Gill (this was right after Gill made global news by publicly supporting the creative commons) and said the line that all this background was just meant to let me quote:
“The root word of amateur in Latin is Amare, meaning ‘love’. Amateur literally means he who does it for love as opposed to one who does it for money. I believe a labor of love is likely to be higher quality than one done for money – so amateur is a compliment”.

Nathan was happy to accept amateur in that sense, and the editor happy to have Nathan shut up didn’t seem to mind that this meant conceding the amateurs were better at it than he was :p

Claudio that day opened my eyes to why amateur work can be so enormously powerful. Why projects like kongoni can work even though nobody is getting paid for it. This is not professional labor, when I have other things to do – I don’t work on it, it’s just a hobby – yet it’s a very nice system on par with some of the best professionally created systems out there.
It’s matching them, despite having basically no budget, a small development team – and a longer release cycle.
Because we’re doing it for the love of it. We love working on this, it’s fun, we get the reward of a piece of software we truly enjoy using, and the righteous feeling of knowing that we are not only doing this ethically but promoting the growth of ethically created and distributed software (or free software for short).

We’re doing it because we love to do it – and that’s why it’s good.

Share|

FSF and Cisco settles their lawsuit

Diary 14 Responses »

May 212009

I have been meaning to comment on the FSF/Cisco lawsuit for some time. Blogposts on it has been interesting, with a general feel being that people hoped for a settlement.
While a settlement is certainly a good thing because long expensive lawsuits is probably the least practically beneficial way for the FSF to spend their time and money – the general reason the blogsphere noted rubbed me the wrong way.
“Cisco has been a quite linux-friendly so we should hope to resolve this quickly”.

Sorry ? What ? Cisco may have been willing to use and interoperate well with FOSS but that’s a far-cry from being friendly. Violating copyright licenses is not friendly – even if it’s copyleft licenses. CISCO’s own software is still almost entirely proprietary and while their systems are very good – they are hardly a good friend to free software. Using linux and other free software to power their linksys routers was a great technical decision – but to do so in ways that outright violated the terms of the license is despicable.
I am generally unable to have a moral problem with people who ignore exploitive and abusive license terms – but when the only terms in the license are put there to protect the freedom of users, ignoring them is nothing short of an outright insult to software freedom.
This was not users copying music files from their friends – this was a corporation trying to benefit from software freedom while denying it from their users.

Having read through the terms of the settlement I must say it seems like the FSF didn’t cave at all – for which I applaud them. The settlement not only ensures that CISCO has a solid agreement to abide by their responsibilities under the copyleft licenses, but also includes a number of reparations for damage previously done by not fulfilling these obligations.

I do believe that this is also a legal victory for free software. After ignoring the FSF’s attempts at a friendly agreement for years, CISCO clearly felt that their chances in court were just too slim to keep arguing once that became a reality – the settlement really only establishes the status quo that should have been in place the first time CISCO shipped a GPL’d program, but in settling CISCO has given a clear message that the GPL is something they aren’t prepared to take on in court.
All in all – a settlement that basically amounts to everything the FSF wanted in the original suit was just a cheaper and more effective way of winning.

Share|

Older Entries