Well, my H/FOSS class is coming to an end. In a few short hours, I’ll finish my last H/FOSS class with a presentation on our work on Sugar (coincidentally it’s also my last college class).

At this point, I’ve realized that Sugar is a fairly disorganized project. It seems like it’s constantly in flux, with multiple wikis, bugtrackers, git repos, etc. It’s very confusing to get started deving on - probably the most difficult project to enter in my experience in FOSS.

That being said, walking away will be hard…well, not that hard since I don’t plan on walking away just yet.

I was assigned some tasks by the team after my initial set of patches, so I’ll make sure to finish those up. Then what? I’ll probably run away and never look back.

While I can appreciate the work the Sugar devs do, it’s not a project that I find particularly compelling, so I plan on leaving it once I’ve submitted my last set of patches.

After a late start, Matt and I have been blazing ahead on development of Sugar. As of this writing, we have 6 (almost 7) patches merged into Sugar upstream.

The biggest hurdle in getting Sugar installed was that I wasn’t running it on a supported OS. I was building and testing on Fedora 19, where it only supports Fedora 18 and Ubuntu whateverthefuck.

As a result, my first 5 patches fixed various problems with the build system, including adding support for Fedora 19. After some vigorous testing and discussion, all 5 patches were merged in.

Afterwards, I found a crash in the journal caused by mousing over the Pippy activity icon. The crash was caused by a call to a deprecated function…a function prevalent across the entirety of Sugar. My 6th and 7th patches are fixing this sweeping problem.

While we haven’t quite fixed the kinds of usability bugs we first set out to fix, we are making a significant impact on Sugar and are helping fix the contribution process.

Hey all,

It’s Thursday during H/FOSS class, which means that it’s time for an update on my progress with Sugar.

We’ve made very little progress - we’ve uncovered some more network-related usability bugs, but haven’t produced any working code yet.

Our environments have been set up, however Matt’s got blown away in an OS reinstall.

Sugar progress has been slow so far - Matt and I have mostly been working on administrative stuff.

I specifically set up the project page, and communicated with the sugar community about the validity of some of our bugs.

Not much more to report than that.

Hey everyone! I made a Perl seminar for CSH!

Here it is!

And here is the code!

This isn’t even close to conclusive, but it does give you a basic introduction.

I cover certain topics that are important, and omit ones that are actually bad (default variable, 2 argument open).

Surprisingly enough, this post is not for my FOSS class.

Anyway, this article has been circulating around my network lately, and it led me to think about my stance on open source.

I love open source software, both writing it and using it.

Why?

First and foremost, I’m a student. Learning is quite literally my profession. And hopefully after I graduate in May, I’ll continue to learn. I love technology because to be truly successful, you need to continue to learn throughout your career.

Open source allows me to learn by working with other people’s code. Whenever I jump into a large codebase, I tend to pick up techniques and design strategies employed by the original programmer. By doing this, I’ve also gotten progressively better at jumping into large projects quickly and figuring out exactly what I need to do to add whatever feature or fix whatever bug.

I also tend to get frustrated by poor software. There are a lot of open source projects that I like that lack features, or are bug-ridden. Whenever I get pissed off by something that doesn’t work, I can fix it. And then I can push my changes upstream and fix it for everyone. Not only is it empowering, but I don’t have to change my workflow/program to account for other people’s broken code.

A benefit of pushing your code upstream is the feedback you get on it. Most open source developers will analyze your code before they merge it in, give you feedback and allow you to fix your change. It’s a great way to get some constructive criticism on your code.

But the best benefit to working on open source is how it enhances my résumé. As I mentioned before, I’m a student. There was a point where I was struggling to get my first post-college job in the field. Having a github filled with open source projects that I’ve pushed to as well as open source projects of my own was a huge advantage over the competition - it helped me really stand out.

Never will I parrot the fucking notion that all software should be Free - it shouldn’t be. I’ll never support viral open source licensing - that’s not freedom and that hurts businesses, both small and large.

But I will say that open source is invaluable to students looking to get out into industry, and that it allows people already in industry to train old skills as well as learn new ones.

So, first, I royally messed this up when I first committed this blog entry, and wrote about 3 things I enjoyed doing, rather than writing about 3 Sugar activities. That post has been removed - largely out of embarrassment

That being said, here are my three favorite Sugar activities.

Wine

The first activity I find interesting is Wine. This isn’t because I think the Wine project is particularly interesting by itself, but because I find it surprising that Wine has been “ported” to the OLPC as well as its reception.

One reviewer basically says that it’s how he does normal computing on his OLPC, which is curious to me, as there really ought to be Activities to handle his needs (in this case, playing games and listening to music).

Etoys

Etoys was pretty much guaranteed to make this list, as I’m (obviously) a programmer. It seems like a smart way to make programming more appealing to children, so that they can get hooked at a young age.

GetBooks

GetBooks looks great, as it makes book acquisition trivial for people who want to read. I’m not sure what kinds of books you can find using OPDS, but the idea by itself is laudable. I honestly can’t wait to see what kinds of texts are available to me.

CFEngine is a fantastic tool for managing configuration files and packages across heterogeneous environments. I figured I could use it to maintain a basic set of installed packages across my Debian, OpenBSD and FreeBSD systems.

Except that the FreeBSD package_method promises in the cfengine standard library suck.

They use FreeBSD packages, and unless you have a box building your own sets of FreeBSD packages…packages suck. They are built with all of the bells and whistles, ergo they pull in a ton of shit you probably don’t need on your system.

So I wrote a package_method promise that instead uses portmaster to install and remove packages. Here’s the code:

body package_method freebsd_portmaster
{
    package_changes => "individual";

    package_list_command => "/usr/sbin/pkg_info";

    package_list_name_regex    => "([^\s]+)-.*";
    package_list_version_regex => "[^\s]+-([^\s]+).*";

    package_installed_regex => ".*";

    package_name_convention => "$(name)";
    package_delete_convention => "$(name)-$(version)";

    package_file_repositories => {
        "/usr/ports/accessibility/",
        "/usr/port/arabic/"
        "/usr/ports/archivers/",
        "/usr/ports/astro/",
        "/usr/ports/audio/",
        "/usr/ports/benchmarks/",
        "/usr/ports/biology/",
        "/usr/ports/cad/",
        "/usr/ports/chinese/",
        "/usr/ports/comms/",
        "/usr/ports/converters/",
        "/usr/ports/databases/",
        "/usr/ports/deskutils/",
        "/usr/ports/devel/",
        "/usr/ports/dns/",
        "/usr/ports/editors/",
        "/usr/ports/emulators/",
        "/usr/ports/finance/",
        "/usr/ports/french/",
        "/usr/ports/ftp/",
        "/usr/ports/games/",
        "/usr/ports/german/",
        "/usr/ports/graphics/",
        "/usr/ports/hebrew/",
        "/usr/ports/hungarian/",
        "/usr/ports/irc/",
        "/usr/ports/japanese/",
        "/usr/ports/java/",
        "/usr/ports/korean/",
        "/usr/ports/lang/",
        "/usr/ports/mail/",
        "/usr/ports/math/",
        "/usr/ports/mbone/",
        "/usr/ports/misc/",
        "/usr/ports/multimedia/",
        "/usr/ports/net/",
        "/usr/ports/net-im/",
        "/usr/ports/net-mgmt/",
        "/usr/ports/net-p2p/",
        "/usr/ports/news/",
        "/usr/ports/packages/",
        "/usr/ports/palm/",
        "/usr/ports/polish/",
        "/usr/ports/ports-mgmt/",
        "/usr/ports/portuguese/",
        "/usr/ports/print/",
        "/usr/ports/russian/",
        "/usr/ports/science/",
        "/usr/ports/security/",
        "/usr/ports/shells/",
        "/usr/ports/sysutils/",
        "/usr/ports/textproc/",
        "/usr/ports/ukrainian/",
        "/usr/ports/vietnamese/",
        "/usr/ports/www/",
        "/usr/ports/x11/",
        "/usr/ports/x11-clocks/",
        "/usr/ports/x11-drivers/",
        "/usr/ports/x11-fm/",
        "/usr/ports/x11-fonts/",
        "/usr/ports/x11-servers/",
        "/usr/ports/x11-themes/",
        "/usr/ports/x11-toolkits/",
        "/usr/ports/x11-wm/",
    };

    package_add_command => "/usr/local/sbin/portmaster -D -G --no-confirm";
    package_update_command => "/usr/local/sbin/portmaster -D -G --no-confirm";
    package_delete_command => "/usr/local/sbin/portmaster --no-confirm -e";

    expireafter => 240;
}

The only interesting thing about the body of the promise is that I’m using package_file_repositories in a way that it was never intended to be used. Since the port names needed to be provided to portmaster in a

I use CFEngine on my personal site to manage my configuration. I have an SVN repo on one box that I can push configuration changes to, and then from there, the changes get pushed out to all of my boxes.

One problem that I encountered is that changes to my CFEngine configurations that had syntax errors would be pushed out to all of my machines, and cause them to fallback to the failsafe configuration, which is less than ideal.

My solution was to write a pre-commit hook for my SVN repo that would prevent me from checking anything in that would break my configuration.

#!/bin/bash

REPOS=$1
TXN=$2
LOG="/home/svn/commit.log"
CHANGES=0

if [[ "$1" = "" && "$2" = "" ]]; then
  echo "Most be called as $0 REPOS TXN" >> "$LOG"
  exit 1
fi

AWK="/bin/awk"
GREP="/bin/grep"
RM="/bin/rm"
ECHO="/bin/echo"
SED="/bin/sed"
SVN="/usr/bin/svn"
SVNLOOK="/usr/bin/svnlook"
SVN_URL="file:///home/svn/cfengine/trunk"
CF_PROMISES="/usr/sbin/cf-promises"

PROMISEDIR="/home/svn/.cfagent/inputs/"
MODULESIDR="/home/svn/.cfagent/modules/"

"${ECHO}" "REPOS ${REPOS}" >> "$LOG"
"${ECHO}" "TXN ${TXN}" >> "$LOG"

"${ECHO}" "Checking out working copy from $REPOS ...." >> "$LOG"
"${SVN}" co --depth immediates "${SVN_URL}/cf-agent_policies" "${PROMISEDIR}" > /dev/null
if [[ $? -ne 0 ]]; then
  "${ECHO}" "Failed to get fresh working copy" >> "$LOG"
  exit 1
fi

"${SVN}" co --depth immediates "${SVN_URL}/cf-agent_modules" "${MODULESIDR}" > /dev/null
if [[ $? -ne 0 ]]; then
  "${ECHO}" "Failed to get fresh working copy" >> "$LOG"
  exit 1
fi

# Figure out what directories have changed using svnlook.
FILES=`${SVNLOOK} changed ${REPOS} -t ${TXN} | ${AWK} '{ print $2 }'` > /dev/null

for FILE in $FILES; do
  "${ECHO}" "file changed ${FILE}" >> "${LOG}"
  if [[ $("${ECHO}" "${FILE}" | ${GREP} cfengine/trunk) != "" ]]; then
    if [[ $("${ECHO}" "${FILE}" | ${GREP} generic_cf-agent_policies) != "" ]]; then
      if [[ $("${ECHO}" "${FILE}" | "${SED}" -e 's/home\/svn\/cfengine\/trunk\/cf-agent_policies\///g') != "" ]]; then
        CHANGES=1
        "${SVNLOOK}" cat "${REPOS}" "${FILE}" -t "${TXN}" > ${PROMISEDIR}/$("${ECHO}" "${FILE}" | "${SED}" -e 's/home\/cfengine\/trunk\/cf-agent_policies\///g')
      fi
    fi
  fi
done

if [[ ${CHANGES} -eq 0 ]]; then
  exit 0
fi

"${CF_PROMISES}" --dry-run > /dev/null
if [[ $? -ne 0 ]]; then
  "${ECHO}" "Syntax error! Aborting commit!" >> "${LOG}"

  "${RM}" -rf "${PROMISEDIR}"
  "${RM}" -rf "${MODULESIDR}"

  exit 1
fi

"${RM}" -rf "${PROMISEDIR}"
"${RM}" -rf "${MODULESIDR}"

This should be the pre-commit file in the hooks directory of your SVN repo. If that file exits with a non-zero code, the commit will fail. The file must be executable by the svn user.

NOTE: Hey! This is a book review I wrote some time ago that was published here. This review is outdated, mostly because there IS a new edition about the last major release of perl, perl 5.14. Because of the release of the new edition, I thought it might be good to reproduce the review on my blog.

The camel book is a book that needs no introduction. The Perl community considers it the ultimate Perl book, and rightfully so, as it is written by Larry Wall himself (also Christiansen and Jon Orwant)!

The camel book is an in-depth look at the Perl programming language. The book does a fantastic job explaining how to use the language, the more powerful aspects of the language, as well as some of the implementation details of the compiler. As you progress through the book, it constantly builds upon itself. Different quirks/features of the language which are first introduced as black magic are explained in exhaustive detail later on. For example, you first learn about what the autoload pragma is, followed by advanced usage of goto, and then they tie that together by detailing how autoload is implemented with gotos. As a side note, I know this sounds gross, but gotos aren’t what you think they are in Perl… at least not always.

The writing is, for the most part, very clear and understandable, and contains a heavy dose of humor. The humor is definitely welcome, as the text would be horribly dry without it. The humor also tends to be representative of the Perl community at large, which is fabulous for the new Perl programmer. The only problem I had with the writing style was the chapter on regular expressions. In this chapter, the wording is murky at times, and more examples would be a welcome addition. Like I said though, this is only one chapter.

The biggest problem with this book is that it’s old. The latest edition (3rd at the time of this writing) only covers up to Perl 5.6. We’re at Perl 5.12 now, with 5.14 on the horizon, and a significant amount has changed. However, that doesn’t make this book irrelevant. I think it makes a wonderful companion to Modern Perl by chromatic. Once someone has a handle on how to write modern Perl (>=5.10), this book is definitely a great look at the rest of Perl as well as an interesting peek into the internals of the language. Regardless of recent developments in the language, this book still has a significant amount of relevant content.

If you want to truly become a Perl master, you need a copy of this book, but keep in mind you’ll also probably want a book that covers more modern Perl.