This is the first public release, under GPLv3. The software is now in a state where I can use it every day to maintain chroots. To download the source code, use the link below. There is also a git repository available for cloning. Chroots is developed under Ubuntu, and can build debian and Ubuntu chroots through deboostrap.

Source Code: chroots-0.2.tar.gz
Git Repository: http://git.digitalself.org/?p=chroots.git

If anyone finds this useful, don’t hesitate to drop a comment with suggestions or feedback. I’m looking forward to it. Bug reports are nice, and will be handled. More information about chroots below, and inside the source package. In time, I might put up a page for the project. In the meantime, enjoy this release.

About Chroots

Chroots is a set of wrapper scripts around  debootstrap. debootstrap is an effective way of create a general purpose build environment. While it is fairly simple to setup a working environment, it’s always necessary to perform several steps to actually login into a deboostrapped environment using chroot. It can be a cumbersome task, hence chroots.

For test building packages there is already pbuilder. What pbuilder does is build a debian package in a freshly created chroot environment. This allows detecting build and dependency errors quite effectively. Nevertheless, to use pbuilder, an environment is setup every time and out of the user’s reach, and it is quite a difficult tool to use for the occasional packaging experiment.

This is where chroots comes in. It allows to easily configure setup and deploy a chroot environment, enabling everything from package tests to dependency check, or manual tarball compilation, keeping your production environment ‘clean’. It allows to maintain several chroot environments at the same time, so that it can be easy to test multiple systems.

You should have the medibuntu repository enabled for this to work.

Get some tools to build tje package along with the ffmpeg source in Ubuntu Intrepid. Then get the appropriate packages to build ffmpeg, and satisfy the evil codec dependencies:

apt-get install dpkg-dev devscripts
apt-get source ffmpeg
apt-get build-dep ffmpeg
apt-get install libmp3lame-dev libfaac-dev libxvidcore4-dev libx264-dev

To finished up, go into the sources directory, build the package with the external codecs and install everything after it finishes building the debian package. Note that the first command is optional, and is just to bump the package version so that is “newer” that the original repositories:

dch -i
DEB_BUILD_OPTIONS=externalcodecs dpkg-buildpackage -rfakeroot -us -uc

dpkg -i *.deb

And that is it. Look for scripts that use ffmpeg to encode stuff for the PSP or iPod. There are plenty around. I’ll post my favourite at a later time.

#!/bin/bash

STRING=$1
STRLEN=${#STRING}

A=${STRING:1:$STRLEN-2}
echo ${STRING:0:1}${#A}${STRING:$STRLEN-1:$STRLEN-1}

Try running internationalization on it.

With Epiphany using the gecko backend, it was hard adding exceptions for every website using self-signed certificates, or broken certificates, including my own, due to the interaction which was covered in Firefox but no in Epiphany. I even started my own Certificate Authority (it’s just a bash script). All of this made me give Firefox a try for a while..

But, after a while, I have come to dislike all the things that made switch to Epiphany in the first place. It’s slugish, it eats all my memory, and makes me squirm in pain…

On the other hand, Epiphany feels lightning fast, snappy and doesn’t eat all my RAM. Meanwhile, with the updates in Ubuntu Hardy 8.04.1 adding SSL exceptions is not a broken process that equals fail. It shouldn’t be easy though, but it should be doable.

Does anyone have any hard facts if the page rendering is faster on Epiphany than on Firefox ? Or is that just a “feeling” people get ?

I can only wait to check out Epiphany with webkit! In the meantime, I’ll take it as it is, and make it my default once again.

After trying a couple of methods and improving on my system over six months, I can recommend a system that works for me. A while back I was using text files with the mindset of doing lists, lists and more lists. This is still true. I need to capture all my open loops, thoughts, tasks and projects into lists that I am sure I will review, where review is the key word.

But I realized that text files are not that flexible for certain things, which require some extra markup. I need something I can quickly click to access my GTD Lists. And I need a List that presents me with stuff I can do next (the next actions list). This should all be clickable and fairly dynamic, like a wiki or something similar.

Enter Tomboy Notes. Tomboy allows you to keep a set of notes only a click away. The notes enable linking and formating, and while simple, build a solid foundation for a GTD system.

Life Contexts

To get going with GTD and Tomboy Notes, I use what I call Life Contexts where different projects live, usually Personal and Work contexts. Each of these is a different Tomboy note. I do this because I generally won’t be looking at personal things at work, or work things at home. This is something that annoys me in most GTD applications, since I tend to try and keep these worlds separate, and one context just gets in the way of the other when they appear together. Most applications use location contexts, which i tried for a while, but found out that about 70% of my tasks (personal and work) are “@computer”, making the workflow suck more than less.

The Notes

My system uses one note per life contexts and two special contexts making up for 4 Tomboy notes:

• Work ToDo List
• Personal ToDo List
• Short List
• Inbox

Each Life Context Note, Work and Personal, holds projects linked to that context. There should be as many notes as contexts you need have so that the right tasks pop up at the right time.

The two remaining notes are for reviewing purposes and to increase your trust in the systems.

Projects

Projects appear within there context and should be visually separate from other projects, with a set of common fields. You should keep track of why your doing things (Desired Outcome) and what is the status of it (Current status). The visual separation is pretty important to me, because it enables me to quickly distinguish between projects and tasks, enhancing the review process.

Below is a sample note for your copying and pasting. Look at the image above for the formating.

===========================================================================
Improve GTD Work Flow

Desired Outcome: Get my life in order with GTD
Current Status: Draft of blog entry complete
Next Actions:

- Publish a blog entry
    - Brainstorm the content
    - Write the text
- Organize open loops on physical inbox
==========================================================================

I create projects based on things I have on my mind that require more than a few actions. The extra fields is to help me keep the eye on the ball, and employ the GTD methodology. For further insight, buy the book. When reviewing I always look at the desired outcome, and so should you, regardless of the system you use. Focus is crucial to avoid procrastination.

Items that are very short I keep on a special project which is “Minor Tasks”, both in personal and work contexts. This holds minor projects or errands that will never hold more than a couple of actions. A rule of thumb is if it only has one status (done or not done) and the outcome is the task itself with no grand plan behind it, then it’s probably a minor task.

Sometimes, when projects get too big, I temporarily keep track then in a separate notes, since I don’t want it cluttering the review process, which is the master piece of the system. But, in time this approach gets hard to manage because it makes you explicitly click the note to review project status.This increases the resistance to actually get anything done and leads to failure.

The project oriented view depending on life context makes it easy to create actions, to parse the current status of projects and quickly review them. I can quickly access my work stuff and look at it by clicking the corresponding tomboy note.

Putting it all together with the Short List

The “Short List” is a subset of things to do Next, organized by context. It’s nothing more than a subset of Next Actions (read the book). I use special formatting on the short list entries to keep track of what project they belong to, enabling a quick decision on what to do next. So they end up looking like “Project@Task”, to satisfy my GTD needs.

The special steps are to use the Tomboy linking capabilities and create a few items that help. Both Titles “Work ToDo List” and “Personal ToDo List” take me to the respective life context notes. So keep entries to your contexts on the Short List. And on each note (context) I put a little link at the top that takes me to the short list ([short list]), so I can quickly access it and check what to do next. Look at the list figures above to get the idea.

As I get things done I strikeout the concluded task, and later on, when I review the current status of each project, I remove those tasks. But I always remove tasks from the short list when done, review and update the shortlist so that it’s always clean,updated and as much to the point as possible.

The Inbox Note

Last but not least, there is the Inbox. This is not a real inbox, but rather a temporary placeholder for things you will need to review. Things on this list might end up in the Minor projects, as a new project or even in the trash can. This just assures you that you will make act on the item you put there, but don’t necessarily have the time to it right now. You can also link to this note from the Short List and make entries there to assure you that you will review it.

Trust

All of the suggestions and hints are to help you Trust Your System. By ensuring that you have all the projects reviewed and updated, and a place to check what to do next, you assure yourself that you have all the open loops covered and tied down, resulting in stress free productivity. Isn’t it great ?

Install compile tools and git:

sudo apt-get install build-essential autoconf automake libtool pkg-config git-core

Install driver dependencies, now with dri deps also:

sudo apt-get install libdrm-dev x11proto-gl-dev mesa-common-dev xutils-dev \
x11proto-xf86dri-dev x11proto-fonts-dev x11proto-randr-dev x11proto-video-dev \
x11proto-xext-dev x11proto-render-dev xserver-xorg-dev

Checkout the source code:

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/

Last but not least, compile and install

cd xf86-video-radeonhd/
autogen.sh --prefix=/usr --enable-dri
make
sudo make install

And you’re all set. Don’t forget to change the driver to radeonhd on your /etc/xorg.conf.
I’ll try to follow this up with the -ati counterpart… For now, go test. Feedback welcome.

On a related topic, I’m still to figure out the best software to handle podcasts. Right now i’m using rhythmbox, but I’m giving banshee a try.I’ve also been playing with Itunes on wine, but I have no interesting things to report, either than it would be good to have a linux version of it, since the Itunes store is quite interesting.

Big Buck Bunny was released on May 30th. It’s great to see that not only operating systems can be open source. I really love the open source model. This movie is the result of a Blender Foundation initiative know as Project Peach. The movie is licensed under the Creative Common Attribution 3.0.

Download and see, hey it’s free. I was thinking of getting the half HD version, since my screen doesn’t do Full HD, but what the heck, live a little.

Don’t forget to buy the DVD if you want to show your appreciation.

The work flow is simple: Develop and test locally, deploy remotely. I’m currently applying this towards the development of an improved theme for my blog, which is basically this one, plus minor adjustments.

My setup is an Apache 2 webserver, with PHP and mySQL. On top of this I enable user dirs for the webserver, and deploy a local wordpress, which in fact runs a backup database from my production site.

First , install apache2,php and mysql support:

sudo apt-get install apache2 php5 libapache2-mod-php5 mysql-server

Now enable user directories support (things like localhost/~jonhdoe which actually live in /home/johndoe/public_html) and create the public_html folder:

sudo a2enmod userdir
mkdir $HOME/public_html

Another twist, since this is my main workstation and I don’t want an apache+mysql setup running all the time, is to remove all of the startup scripts from the default boot runlevels:

sudo update-rc.d -f mysql remove
sudo update-rc.d -f apache2 remove

I then run a script to start my environment when I want to code some web bits:

#!/bin/bash

/etc/init.d/apache2 start
/etc/init.d/mysql start

Don’t forget to make the script executable:

chmod +x bin/start-web-dev.sh

After all this I just installing web apps locally. In my case I just install WordPress by uncompressing it into public_html, creating a DataBase using phpmyadmin, and running the install. After that I went to my production wordpress exported the DB, and imported it on the local wordpress. And I’m done.

As a finally twist I created a git repository of my theme, so i just modify+commit+push, and pull on the main website. Since I can push only when I need or can, this setup is really working for me.

Any further enhancements are welcome, so feel free to drop some suggestions to improve on this.